perm filename FRM.MSG[P,JRA]1 blob
sn#428325 filedate 1979-03-24 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00081 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00012 00002 ∂15-AUG-75 1817 ESS,JMC
C00014 00003 ∂21-NOV-75 2027 FTP: host MAXC
C00016 00004 ∂11-Aug-77 0447 RPG New MACLSP
C00020 00005 ∂02-Nov-77 1616 JP MACLSP meta-D directory feature
C00022 00006 ∂06-Nov-77 1503 RPG New features.
C00024 00007 ∂21-Jun-77 0718 FTP:PRATT at MIT-AI (Vaughan Pratt )
C00026 00008 ∂08-Dec-76 0108 100 : mjc
C00027 00009 ∂24-Nov-76 1518 RPG Debug/Step (SAIL)
C00037 00010 ∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
C00038 00011 ∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
C00039 00012 ∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
C00042 00013 ∂26-Feb-77 1624 RPG Eread
C00043 00014 ∂19-May-77 0118 JP running E from maclsp
C00044 00015 ∂01-Jul-77 2212 DCO MAIL in MACLSP
C00047 00016 ~This is first attempt to write evaluator for extension of lisp
C00051 00017 ~THE PREDICATES
C00054 00018 ~THE CONSTANTS
C00055 00019 ~THE CONSTRUCTORS
C00056 00020 ~PRIMITIVE APPLICATIONS--DELTA RULES
C00059 00021 ∂04-AUG-76 0908 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI) Hiya back
C00064 00022 ∂10-SEP-76 1253 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI)
C00065 00023 ∂03-Dec-76 2304 FTP:GLS at MIT-MC (Guy L. Steele, Jr. )
C00068 00024 ∂04-Dec-76 1321 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
C00070 00025 ∂27-Dec-76 1247 FTP: host AI xxx
C00071 00026 ∂06-Nov-77 1159 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) grumble, grumble
C00078 00027 ∂04-Mar-79 1040 PEAGRE at MIT-MC (Philip E. Agre) ''Functions ...'' revisions
C00089 00028 ∂20-OCT-76 0944 RPG
C00091 00029 ∂25-OCT-76 1043 RPG
C00092 00030 ∂28-Oct-76 2107 RPG BOOK
C00099 00031 ∂10-Nov-76 1351 RPG PROGV Feature
C00101 00032 ∂11-Dec-78 1724 RPG NEWIO programming tips
C00103 00033 ∂21-Dec-78 1219 RPG Bug fix in NEWIO
C00105 00034 ∂09-Jan-79 1542 RPG MacLisp matcher
C00108 00035 ∂17-Jan-79 1546 RPG UTIL.>
C00109 00036 ∂07-Feb-77 1207 HJS via NBST Urmi
C00112 00037 ∂14-JAN-76 1318 FTP: host HARV
C00119 00038 ∂24-Jan-79 2120 MCGUIRE at USC-ECL August BYTE a possible paper
C00121 00039 ∂22-DEC-75 0127 FTP:GLS at MIT-AI
C00124 00040 ∂23-DEC-75 1117 FTP:GLS at MIT-AI
C00125 00041 ∂30-DEC-75 0556 FTP:GLS at MIT-ML
C00126 00042 ∂01-JAN-76 0639 FTP:GLS at MIT-ML
C00127 00043 ∂19-JAN-76 1220 FTP:GLS at MIT-ML
C00129 00044 ∂12-FEB-76 0845 FTP:GLS at MIT-AI
C00133 00045 ∂03-Mar-77 1603 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) Knight displays
C00138 00046 ∂01-Feb-78 1057 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) last message
C00139 00047 ∂25-Jan-79 1821 GLS LISP etc.
C00141 00048 ∂19-MAR-76 0150 HPM
C00144 00049 ∂27-Feb-78 1706 HPM more video
C00152 00050 ∂29-Oct-76 1101 RPG GRIND
C00154 00051 ∂14-Dec-76 2221 RPG Printing windows/SAIL
C00155 00052 ∂09-Jun-77 1415 RPG sewer OLDIO
C00157 00053 ∂23-FEB-76 1503 FTP: host HARV
C00165 00054 FORREST W. HOWARD JR.
C00166 00055 ∂09-MAR-76 1311 FTP:HOWARD at HARV-10 LISP/BOOK
C00169 00056
C00173 00057 ∂24-MAY-76 1141 FTP: host HARV
C00177 00058 ∂02-May-78 1245 MG ML (LCF metelanguage)
C00179 00059 ∂19-Jul-77 1436 JP
C00180 00060 ∂06-Apr-78 1232 RPG New Maclsp
C00186 00061 ∂03-Jan-79 0719 RWW
C00197 00062 ∂05-Dec-78 0721 JFR via LCSR-TIP rumor
C00198 00063 ∂05-Dec-78 0833 RG at MIT-AI (Richard Greenblatt)
C00199 00064 ∂08-Jan-79 1338 STOUTE at MIT-MC (David Stoutemyer)
C00200 00065 ∂11-Jan-79 0857 PWM RANDOM
C00208 00066 ∂15-Jan-79 0548 PEAGRE at MIT-MC (Philip E. Agre)
C00210 00067 ∂18-Jan-79 1732 PEAGRE at MIT-MC (Philip E. Agre) Byte Article (trials & tribs.)
C00213 00068 ∂21-Jan-79 1212 PEAGRE at MIT-MC (Philip E. Agre) Abstract of ''Functions as...'' (150 lines)
C00224 00069 ∂01-Feb-79 1642 PEAGRE at MIT-AI (Philip E. Agre) Functions as Data Objects (pant, pant...)
C00226 00070 ∂15-Jan-79 2002 BAK at MIT-MC (William A. Kornfeld) Byte Magazine
C00228 00071 ∂16-Jan-79 0924 LAASER at PARC-MAXC2 a copy of my thesis
C00229 00072 ∂18-Jan-79 1954 BAKER at MIT-AI (Henry G. Baker, Jr.) Lisp, etc.
C00230 00073 ∂21-Jan-79 2044 BAKER at MIT-AI (Henry G. Baker, Jr.) Lisp article
C00232 00074 ∂18-Jan-79 2146 CARL at MIT-AI (Carl Hewitt)
C00233 00075 ∂20-Jan-79 1445 Boyer at SRI-KL (Bob Boyer) Your book reviewed
C00235 00076 ∂20-Jan-79 1754 RZ at MIT-MC (Richard E. Zippel)
C00237 00077 ∂22-Jan-79 0637 RLB,RWK,RZ,HIC at MIT-MC BYTE paper on LIL
C00238 00078 ∂04-Feb-79 1226 RWK at MIT-MC (Robert W. Kerns)
C00243 00079 ∂21-Jan-79 0944 PHW at MIT-AI (Patrick H. Winston)
C00244 00080 ∂21-Jan-79 1528 BAK at MIT-MC (William A. Kornfeld) BYTE article
C00250 00081 ∂03-Feb-79 1116 BAK at MIT-MC (William A. Kornfeld)
C00251 ENDMK
C⊗;
∂15-AUG-75 1817 ESS,JMC
Where do you currently stand as a graduate student? What exams have you
passed, etc., and how long were you a student before you dropped out?
These matters are relevant to your readmission, and I am the new
chairman of the Admission's Committee. I think, though I am not sure,
that you may have to deal with us. Well, maybe its the graduate study
committee. In any case, it may be necessary to see a plan that will
plausibly lead to a prompt thesis, and, in any case, such a plan will
be relevant to whether we would support you. If you had a thesis half
done, it would be even better. I have some plausible thesis problems,
but I would have to be convinced that matters would go quickly.
∂21-NOV-75 2027 FTP: host MAXC
Date: 21 NOV 1975 2027-PST
From: MOORE at PARC-MAXC
Subject: LISP COMPILER
To: JRA at SU-AI
The files are <LISP>COMP and <LISP>LAP. You may use FTP
with name ANONYMOUS (password) anything. Let me know if
you have trouble.
J
-------
∂21-NOV-75 1000 FTP: host MAXC
Date: 21 NOV 1975 0959-PST
From: MOORE at PARC-MAXC
To: JRA at SU-AI
The virtual machine document is not yet available for distriution.
I (unofficially) gave out a copy or two (e.g. Mike Gordon) but
got into trouble over it from PARC management because it has not
yet been cleared through the lawyer that routinely clears
everything that is written at PARC for outside distribution.
So I'm afraid I can't send you a copy of it until its done
and I have pushed it through the clearance mill.
I am looking around for the code for the compiler and will
let you know soon.
Sorry I forgot about your msg.
J
∂11-Aug-77 0447 RPG New MACLSP
To: MACLSP.DIS[AID,RPG]:;
There is a new MACLSP running at SAIL, which has fancy
high segment capabilities such as
1. High segment stored on a separate file
2. Ability to fasload into the hiseg
3. Ability to create pure list space in hiseg
4. Ability to clobber uuolinks (for debuggin)
5. Ability to save high segments anywhere (and get them back under
all sorts of adverse conditions)
The documentation for the above will be available next week. If you
want to use these features, contact RPG.
∂02-Oct-77 2117 DCO MAIL
To: MACLSP.DIS[AID,RPG]:;
Minor update to MAIL in maclsp. (MAIL <destination> <message>)
evaluates <desination> and <message>, and mails the latter to the former.
e.g (mail 'dco x) will send whatever x is to me. (mail <desination>)
will prompt for the message. (mail) will prompt for both <destination>
and <message>.
∂11-Oct-77 1414 RPG
To: MACLSP.DIS[AID,RPG]:;
Modifications to Step (1 bug fixed; 1 feature added):
1. Use (step) as in the manual. That way (step t) inside a break
should work.
2. New feature: (step-hard ...) which is just like step EXCEPT it
works HARDER! Now, working harder is really true so don't use it
unless you need it. Here's what it does: suppose you have
(defun foo (n) ... (bar ...) ...) and foo is compiled and bar
isn't, and you want to step wherein bar. Well, since eval never sees
the compiled call to bar, ordinary (step (wherein bar)) will lose.
But, if you are stepping-hard, the stepper looks around the FIRST
chance it gets to see if it is inside of BAR; this means it searches
the control stack. If it is in bar it prints
<in BAR>
next-form.
-rpg-
∂21-Oct-77 1333 CGN MACLISP MACRO PACKAGE FOR RECORD STRUCTURES
To: MACLSP.DIS[AID,RPG]:;
I have finished a macro package written by Derek Oppen and myself to
facilite manipulating record structures with named components.
As an example, the call (SHELL MNODE COEF UP LEFT ROW COL) could be
used to "create a data-type MNODE" for sparse matrix nodes which has
five components, by defining access and update macros for the
components and an allocation function for MNODEs. You have your choice
between list-structure or MACLISP hunks for the underlying
representation.
The package is documented in SHELL.LSP[LSP,CGN].
∂02-Nov-77 1616 JP MACLSP meta-D directory feature
To: MACLSP.DIS[AID,RPG]:;
Subsribers of the HELP autodef package:
A new feature has been added to SAIL MACLSP to enable obtaining fast
directory listing using RPG's DIRECT fn. It permits use of >,#, and * as
wildcards. To access the package do when talking to MACLSP
βD <filespec> ;;; note: D not d!
where filespec is of the form filnam.ext[p,pn] and where ext,p,pn and the
syntactic delimiters can be omitted in the obvious cases. * wildcards are
allowed for for filnam and ext. If p or p,pn are omitted, they are
obtained from your current crunit device.
Ext can also be > and #. > obtains the largest numbered version, and # denotes
all numbered versions.
Ex:
*.#[lu,ser ;all files with numeric extension in [lu,ser
*.>[foo, ;the file with largest numeric ext in [foo,
*. ;all files w/o ext in crunit dir
...etc...
NOTE: No wildcards allowed in PPN!
∂06-Nov-77 1503 RPG New features.
To: MACLSP.DIS[AID,RPG]:;
There are two new features in maclisp which are callable
after (help) is performed.
1. (dir) returns a list of (filename <ext>) for your aliased ppn
2. (dir foo) returns a list of files for foo,pn
3. (dir foo bar) returns a list of files for foo,bar
4. (directory 'foo 'bar) returns a list of files for foo,bar
5. (dir /1 /1) returns a list of all known ppn's on the system (takes
a LONG time.
6. (esci-enb) enables [esc]i interrupt for the purpose of interrupting
running jobs. [esc]i<x> is equivalent to <call> reenter <x>,
but only works well when NOT in a read (i.e. will attempt
to complete the read first).
-rpg-
∂21-Jun-77 0718 FTP:PRATT at MIT-AI (Vaughan Pratt )
Date: 21 JUN 1977 1018-EDT
From: PRATT at MIT-AI (Vaughan Pratt )
To: JRA at SU-AI
CC: (FILE [PRATT;ENCY MAIL]) at MIT-AI
Well, there certainly is a lot of LISP info there. I've waded through
some of it, and it looks good, but I don't have any substantive
comments yet as I haven't yet seen the woods for the trees.
My article is in AI:PRATT;LISP > if you care to FTP it; alternatively
I can usmail you what exists now. If you ftp it, is it easy for you
to remove all occurrences of backspace-underscore? (They xgp as
italics the way I have things set up here.) If not, I can very easily
remove them here.
Cheers
Vaughan
∂08-Dec-76 0108 100 : mjc
Did you find out anything about Santa Cruz's psych dept?
I met Alan Perlis today. Really neat guy. We talked about teaching
programming--he is very much on the side of the good guys (although
he does APL instead of Lisp).
Wonder if people will mind my trying to change the world once I get
out there?
It was 8 degrees in Chicago when I left. It's nice to be back where
I don't have to wear a parka every time I go out. You should have
seen me in a tux.
∂24-Nov-76 1518 RPG Debug/Step (SAIL)
To: MACLSP.DIS[AID,RPG]:;
DEBUG now knows about STEP in that while inspecting
stack frames, DEBUG will ignore all frames associated with the
single stepping facility.
∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
To: MACLSP.DIS[AID,RPG]:;
The Step package now UNTRACes any function it has to
single step through. Step will print a message informing the luser
of any UNTRACEs performed.
-rpg-
∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
To: MACLSP.DIS[AID,RPG]:;
The ncomplr now parses file names in winning line mode.
In addition, full decoding of files is now
available. Thus you can say:
FOO.FAS[LO,SER]←FOO.LSR[BLE,TCH](KT)
and all will be well.
∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
To: MACLSP.DIS[AID,RPG]:;
The SAIL Maclisp now sports INPUSH/INPOP, which can be
used to do stack-structured input. Delicately based on the
IOPUSH/IOPOP/MTAPE UUO's at SAIL, they can be used as follows:
***FOO.BAR***
.
.
.
'CIAO
(INPUSH LOSING FLE)
'BACK-AGAIN
.
.
.
***LOSING.FLE***
.
.
.
'HI-THERE
(INPOP)
.
.
.
Then (EREAD FOO BAR DSK (LO SER)) produces:
.
.
.
CIAO
(DSK (LO SER)) ;value of (INPUSH ...)
.
.
.
HI-THERE
T ;due to (INPOP)
BACK-AGAIN
.
.
.
Notice that (INPOP) has to occur in the file: simply letting
(READ) run off the end fails! To remedy this, there is a function
called REQUIRE (given an autoload property by (HELP), which will
(PRINT (EVAL (READ))) everything in the file which is REQUIRE'ed.
It is called as: (REQUIRE LOSING FLE DSK (LO SER)) i.e. it has
the same arguments as UREAD. The NCOMPLR also knows about REQUIRE,
and the proper thing to do is:
(DECLARE (EVAL (READ))
(REQUIRE LOSING FLE DSK (LO SER))
which will work whether the file is being read or compiled.
I would discourage the use of these functions, however,
since they depend on black UUO magic and will possibly disappear
with the onslaught on NEWIO around Armageddon.
∂26-Feb-77 1624 RPG Eread
To: MACLSP.DIS[AID,RPG]:;
Eread, the E-file understanding version of Uread now accepts the
following:
(EREAD <file-name> {<ext> default: no extension}{<device> default: DSK}
(<proj> {<prog> default: prog of dskppn}))
where {} indicates optional args and defaults
∂19-May-77 0118 JP running E from maclsp
To: MACLSP.DIS[AID,RPG]:;
File ET.FAS[MAC,LSP] contains LSUBR ET that swaps to E from MACLSP.
Permissible incantations are
(et '(fil)) ;uses E default extensions in disk dir
(et '(fil ext)) ;disk dir
(et '(fil ext (prj prg)))
(et '(fil (prj prg))) ;default ext
(et) ;runs E on last file edited
Notice that the device is always assumed to be DSK.
Bugs, comments → JP
∂01-Jul-77 2212 DCO MAIL in MACLSP
To: MACLSP.DIS[AID,RPG]:;
MACLSP now accepts mail. If you have the (HELP) option, type
(MAIL) to enter the mail program. You will be prompted to give a destination
list and then the message, both of which must be surrounded by double quotes.
Here is an example of its use:
(MAIL)
Destination? (Any valid MAIL destination list surrounded by "s)
"DCO, RPG%SAIL"
Message? (surrounded by "s)
"Notice that a message may run over any number of lines and may contain
any characters. If you want a double quote in your message, type it twice
as in "". The message now ends."
It is generally faster to send mail using (MAIL) then to use the MAIL
monitor command because (MAIL) does not start up a separate job. The tradeoff
is that the mail is not delivered immediately, but waits until the remind
phantom checks if there is any incoming arpanet mail. This happens roughly
every ten minutes.
~This is first attempt to write evaluator for extension of lisp
~with form valed variables. this is really (as usual) an evlauaator
~operating on REPRESENTATION(!!!) of lang, but mapping should be smooth!!
~UNDEFINED SHOULD BE CHECKED...CAN OCCUR FROM (CAR @A) ETC...
(DE SOGM (EXP ENV)
(COND
((IS_CONST EXP) EXP)
((IS_VAR EXP) (VALUE EXP ENV))
((IS_COND EXP) (EVCOND (EXPR EXP) ENV))
((IS_FUN_ARGS EXP) (APPLY_S (FUN EXP)
(LIST_OF_EVALED_ARGS (ARGS EXP) ENV)
ENV))
(T UNDEF)
))
(DE APPLY_S(FN ARGS ENV)
(COND
((IS_UNDEF FN)UNDEF)
((MEMBER UNDEF ARGS) UNDEF)
((IS_CAR FN) (APPLY_CAR ARGS))
((IS_CDR FN) (APPLY_CDR ARGS))
((IS_CONS FN) (APPLY_CONS ARGS))
((IS_ATOM FN) (APPLY_ATOM ARGS))
((IS_EQ FN) (APPLY_EQ ARGS))
((IS_NAME FN) ((LAMBDA(Y)(COND((EQ Y FN) (MAKE_FORM FN ARGS))
(T (APPLY_S Y ARGS ENV))))(SOGM FN ENV)))
((IS_LAMBDA FN) (SOGM (BODY FN) (NEW_ENV (VARS FN) ARGS ENV)))
((IS_LABEL (CAR FN)) (APPLY_S (LABEL_BODY FN)
ARGS
(NEW_ENV (LIST (LABEL_NAME FN))
(LIST (LABEL_BODY FN))
ENV)))
(T UNDEF)
))
(DE DENOTE (EXP)
(COND
((IS_NUMBER EXP) EXP)
((IS_TRUTH EXP) EXP)
((IS_FALSE EXP) EXP)
((IS_SEXPR EXP) EXP)
))
(DE VALUE(VAR ENV)
(COND
((NULL ENV) VAR)
((EQ VAR (NAME(FIRST ENV))) (VAL(FIRST ENV)))
(T (VALUE VAR (REST ENV)))
))
(DE EVCOND (EXP ENV)
((LAMBDA(E)
(COND
((IS_UNDEF E) UNDEF)
((IS_TRUTH E) (SOGM (E EXP) ENV))
((IS_FALSE E) (SOGM (OW EXP) ENV))
(T (MAKE_COND E
(SOGM (E EXP) ENV)
(SOGM (OW EXP)ENV)))
)
)(SOGM(P EXP) ENV))
)
(DE LIST_OF_EVALED_ARGS(ARGS ENV)
(COND
((NULL ARGS) NIL)
(T (CONS (SOGM (FIRST ARGS) ENV)
(LIST_OF_EVALED_ARGS (REST ARGS) ENV)))
))
(DE NEW_ENV (VARS VALS ENV)
(COND
((NULL VARS) ENV)
(T (CONS (MAKE_ENTRY (FIRST VARS)(FIRST VALS))
(NEW_ENV (REST VARS)(REST VALS) ENV)))
))
~THE PREDICATES
(DE IS_CONST(EXP)
(COND
((IS_NUMBER EXP) T)
((IS_TRUTH EXP) T)
((IS_FALSE EXP) T)
((IS_SEXPR EXP) T)
(T NIL)
))
(DE IS_VAR(X)(AND(ATOM X)(NOT (IS_CONST X))(NOT(IS_UNDEF X))))
(DE IS_NAME(X)(AND(ATOM X)(NOT (IS_CONST X))(NOT(IS_UNDEF X))))
(DE IS_COND(X)(EQ(CAR X) (QUOTE COND)))
(DE IS_FUN_ARGS (X) (OR(IS_NAME(CAR X))(IS_LAMBDA(CAR X))(IS_LABEL(CAAR X))))
(DE IS_LABEL(X)(EQ X @LABEL))
(DE IS_CAR (X)(EQ X(QUOTE CAR)))
(DE IS_CDR (X)(EQ X(QUOTE CDR)))
(DE IS_CONS (X)(EQ X(QUOTE CONS)))
(DE IS_EQ (X)(EQ X(QUOTE EQ)))
(DE IS_ATOM (X)(EQ X(QUOTE ATOM)))
(DE IS_LAMBDA(X)(EQ (CAR X)(QUOTE LAMBDA)))
(DE IS_NUMBER(X)(NUMBERP X))
(DE IS_TRUTH(X)(EQUAL X REP_TRUE))
(DE IS_FALSE(X)(EQUAL X REP_FALSE))
(DE IS_UNDEF(X)(EQ X UNDEF))
(DE IS_SEXPR(X)(EQ(CAR X) (QUOTE QUOTE)))
~THE CONSTANTS
(SETQ UNDEF @*U*)
(SETQ FALSE @*FALSE*)
(SETQ TRUE @*TRUE*)
(SETQ REP_TRUE (LIST @QUOTE TRUE))
(SETQ REP_FALSE (LIST @QUOTE FALSE))
~THE CONSTRUCTORS
(DE MAKE_FORM(X Y)(CONS X Y))
(DE MAKE_UNARY(F X)(LIST F X))
(DE MAKE_CONST(X)(MAKE_UNARY @QUOTE X))
(DE MAKE_BINARY(F X Y)(LIST F X Y))
(DE MAKE_ENTRY(X Y)(CONS X Y))
(DE MAKE_COND(X Y Z)
(COND
((IS_UNDEF Y) UNDEF)
((IS_UNDEF Z) UNDEF)
(T (LIST @COND X Y Z))
))
~PRIMITIVE APPLICATIONS--DELTA RULES
(DE APPLY_CAR(X)(APPLY_CAR_CDR @CAR X))
(DE APPLY_CDR(X)(APPLY_CAR_CDR @CDR X))
(DE APPLY_CAR_CDR(F Y)
((LAMBDA(ARG1)
(COND
((IS_VAR ARG1) (MAKE_UNARY F ARG1))
((IS_UNDEF ARG1) UNDEF)
((IS_CONST ARG1) ((LAMBDA(ARG)(COND
((ATOM ARG) UNDEF)
(T (MAKE_CONST(F ARG)))))
(CADR ARG1)))
(T (MAKE_UNARY F ARG1))
))
(CAR Y))
)
(DE APPLY_CONS(X)
((LAMBDA(ARG1 ARG2)
(COND
((IS_UNDEF ARG1) UNDEF)
((IS_UNDEF ARG2) UNDEF)
((IS_VAR ARG1) (MAKE_BINARY @CONS ARG1 ARG2))
((IS_VAR ARG2) (MAKE_BINARY @CONS ARG1 ARG2))
((IS_CONST ARG1) ((LAMBDA(A1 A2)(MAKE_CONST (CONS A1 A2)))
(CADR ARG1)(CADR ARG2)))
(T (MAKE_BINARY @CONS ARG1 ARG2))
))(CAR X)(CADR X))
)
(DE APPLY_EQ(X)
((LAMBDA(ARG1 ARG2)
(COND
((IS_UNDEF ARG1) UNDEF)
((IS_UNDEF ARG2) UNDEF)
((AND(IS_CONST ARG1)
((LAMBDA(A1)(NOT(ATOM A1)))
(CADR ARG1)))
UNDEF)
((AND(IS_CONST ARG2)
((LAMBDA(A1)(NOT(ATOM A1)))
(CADR ARG2)))
UNDEF)
((IS_VAR ARG1) (MAKE_BINARY @EQ ARG1 ARG2))
((IS_VAR ARG2) (MAKE_BINARY @EQ ARG1 ARG2))
((AND(IS_CONST ARG1)
(IS_CONST ARG1))
(MAKE_CONST
((LAMBDA(A1 A2)(COND
((EQ A1 A2) TRUE)
(T FALSE)))
(CADR ARG1)(CADR ARG2))))
(T (MAKE_BINARY @EQ ARG1 ARG2))
))(CAR X)(CADR X))
)
(DE APPLY_ATOM(X)
((LAMBDA(ARG1)
(COND
((IS_UNDEF ARG1) UNDEF)
((IS_VAR ARG1) (MAKE_UNARY @ATOM ARG1))
((IS_CONST ARG1) (MAKE_CONST
((LAMBDA(A1)(COND
((ATOM A1)TRUE)
(T FALSE)))
(CADR ARG1))))
(T (MAKE_UNARY @ATOM ARG1))
))(CAR X))
)
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂04-AUG-76 0908 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI) Hiya back
Date: 4 AUG 1976 1208-EDT
From: Guy L. Steele, Jr. (GLS @ MIT-AI)
Subject: Hiya back
To: jra at SU-AI
CC: GLS at MIT-AI
[a] Congratulations on upcoming nuptials.
[b] I have been plowing through chapter six, but
have been very busy lately with MIT projects.
I have not forgotten you, however.
One problem is that I got very frustrated halfway
through the chapter, because of the great profusion
of confusion, and it took a long time to get
up the courage to continue. (Primarily, I was
somewhat annoyed by the radical changes you claimed
were necessary to EVAL to get in shallow binding,
whereas if you had coded the deep binding more
modularly earlier, the changes would be much less drastic.)
Oh well, I'll look forward to seeing new version,
and will passs on my comments on chapter six in any
case when I finish it. Cheers.
- Guy
-------
∂10-SEP-76 1253 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI)
Date: 10 SEP 1976 1552-EST
From: Guy L. Steele, Jr. (GLS @ MIT-AI)
To: jra at SU-AI
CC: GLS at MIT-AI
Ooops, I meant to send off chapter 6 some time ago.
Okay, fair trade. It may take a few days to get all together...
-------
∂03-Dec-76 2304 FTP:GLS at MIT-MC (Guy L. Steele, Jr. )
Date: 4 DEC 1976 0202-EST
Sender: GLS at MIT-MC
From: GLS at MIT-MC (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-MC
Message-ID: <[MIT-MC].17919>
The following mail got routed to some weird destination
at MIT-MC, so I am mailing a copy in case it DIDN't get
to SAIL.
GJS@MIT-AI 12/02/76 20:48:49
To: JOHN at MIT-AI
McCarthy
It's on its way.
∨
GLS@MIT-AI 11/26/76 00:44:20 Re: MONEY, MONEY, MONEY -- also turkey, turkey, turkey
To: GLS at MIT-AI, JOHN at MIT-AI
Allen
much gratitude for the money!
also, recall that "trce, trce, trce" is the best way
to exchange two bits in a pdp-10 ac (see "hakmem"),
and so is appropriate for today.
also great frabjosity today because boston latin
won the latin english game 11-6.
(one day a year i turn into a rabid football fan for
the morning.)
∨
GLS@MIT-AI 11/22/76 12:30:29 Re: lisp
To: JOHN at MIT-AI
CC: GLS at MIT-AI
Allen
One other reference you might want to look at if you haven't
already is:
Fateman, R.J. "Reply to an Editorial." SIGSAM Bulletin 25, pp. 9-11.
I have tried to read the new chapters 2 and 3, but may not have too
much time in immediate future. I'll do what I can.
Presumably what Moses meant was that such details as actually exist
are okay for the public to have. Unfortunately few actual documents
have been produced. That situation should improve in next 6 months.
Meanwhile, I may be able to answer any specific questions
if you need them for the book.
I would be very interested to see Cartwright's work -- I haven't
heard of it.
-- Cheers, Guy
∨
∂04-Dec-76 1321 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
Date: 4 DEC 1976 1620-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].34717>
I assume you meant "hunks". They are essentially a crock,
which I am not entirely proud of, to stave off the address space
crunch in the PDP-10 implementation of MacLISP.
They are essentially short vectors of fixed size; they have
no header as an array does (which occupies 8 words or so).
People generally use them to create small heterogeneous data
structures of more than two components. They take half the space of
a list, since no cdr pointers are needed. They will not
exist on the LISP machine implementation, as the cdr-code
notion yields exactly the same savings, more or less.
Hunks also provide slightly faster access than a list does, but
that consideration is secondary to that of space.
∂27-Dec-76 1247 FTP: host AI xxx
Date: 27 DEC 1976 1547-EST
Sender: gls at MIT-AI
Sent-by: DVM at MIT-AI
Subject: xxx
To: jra at SU-AI
CC: gls at MIT-MC
Message-ID: <[MIT-AI].42656>
No word from McGraw-Hill yet; my thumbs are now getting
quite long. My BS [sic] Thesis is indeed available from
Harvard as a Technical Report. I eagerly await the
publication of the book. Merry Christmas, Happy Chanukah,
Thrilling New Year, usw.
∂06-Nov-77 1159 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) grumble, grumble
Date: 6 NOV 1977 1458-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: grumble, grumble
To: JRA at SU-AI
CC: GLS at MIT-AI
I am told that PASCAL is not as pretty in actuality as people
like to believe; the language definition itself is full of glitches.
(What I am about to say is 1.5-hand information, so double-check
before quoting me.) I am told that the definition explicitly
allows sets to have an implementation-dependent maximum size,
typically 16 or 32. This is evidently so that one can use
single-word boolean instructions to do set operations (e.g. AND
for intersect), and the definers/implementors didn't want to be
bothered with multiple-word operations. Now one of the most
natural sets to deal with, especially when writing the parser
for the compiler, is the character set -- but this set is too
large (at least 64) to represent in most implementations!
I believe that strings also have a maximum length -- but identifiers
do not! This makes it very hard to represent identifiers
as strings in a compiler. I think that in practice the compilers
cheat and limit identifier length.
It may be that in fact there are no dynamically allocatable data
structures in PASCAL at all. You might check out the definition
of EUCLID in SIGPLAN Notices within the past year or two.
All in all, PASCAL is another ALGOL with a couple of good new ideas
(like sets of symbolic constants), but it's not the ultimate answer.
I am busily trying to turn my thesis into a technical report.
I have souped up and cleaned up the compiler a bit more, and will
include it, annotated, as an appendix. Plans are afoot to
experimentally provide lexical scoping on the LISP Machine
and build a RABBIT-like compiler for it. The LISP Machine
otherwise proceeds apace. It has successfully run the Woods LUNAR
program and a good portion of MACSYMA. Tests on LUNAR show that
it is about three times as fast as MacLISP on a KA10, which was
in turn five times faster than in InterLISP. The LISP Machine
has a working compiler and real-time editor. One can use the
editor as the front end to the read-eval-print loop, and the "print"
can go back into the edit buffer in case you want to edit that.
One can have a different editor buffer for each function, and jump
back and forth; there are three commands to exit the editor
(exit, exit and eval, exit and compile). Debugging software is
being developed. Currently undone are bignums, floating point,
interrupts, and the garbage collector. The GC will use Baker's
real-time algorithm (there is never a dead pause, but it is not
asynchronous either; every CONS does a little bit of GC).
The CHAOSNET interface is semi-alive, and the software for it is
being written and tested. The file computer system is being planned.
Eventually there will be a large number of LISp Machines,
all hooked together via CHAOSNET (an Ethernet) to one or more file
computers (which may or may not also be LISP Machines) and the PDP-10s.
The basic LISP Machine idea seems to be working out. The editor is
quite fast, "despite" being written entirely in LISP.
The second prototype is being built; plans call for producing one
production machine a month starting in January.
As for other work, I'm sort of floating about thinking about
writing a Ph.D. thesis proposal. My latest papers were in
SIGPLAN Notices Aug 77 and Proc. ACM 77.
Glad to hear the book is finally about to happen. I can't wait to
see the final product. Have fun out in California, and don't
let the PASCAL types get you down. (You might point out to them
the size of a typical PASCAL compiler compared to a LISP system;
there is a paper in the just-come-out MICRO-10 (SIGMICRO Bulletin)
proceedings about a microcoded LISP machine which makes comparisons
to some other languages -- I think it's by Griss, but there are a
couple of papers of that variety.)
-- Guy
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂04-Mar-79 1020 PEAGRE at MIT-MC (Philip E. Agre) ''Functions ...'' and other Bytery
C00012 ENDMK
C⊗;
∂04-Mar-79 1040 PEAGRE at MIT-MC (Philip E. Agre) ''Functions ...'' revisions
Date: 4 MAR 1979 1340-EST
From: PEAGRE at MIT-MC (Philip E. Agre)
Subject: "Functions ..." revisions
To: jra at SU-AI
John, Don't worry about hurting my feelings by suggesting revisions:
for an unpublished author, the "i'd like to use your paper" is more
than enough to carry one through the "i'd like to revise your manuscript".
Regarding your suggestions, I am in favor of most of them. The
reorganization is a really good idea. Regarding dotted pairs, though,
if we're going to speak of the implementation of LISP, we gotta tell
folks the truth eventually. Now it is possible to low-key it: act like
the dotted-pair notation is a sort of shorthand for the cons node s
structure which is really under consideration. This approach would
be OK by me. I'll leave SETQ vs. DEFINE to your judgement, but again
they have to be told the truth eventually. There is just a gap
in the LISP definition which makes the dynamic addition of variables at
the lowest ("monitor") level not fit in with the rest of the structure
of the language (which can get away with just lambda-defining
all the variables it needs. The "Functions ..." paper is about
*definition* and *implementation*, and I think it
would look a bit strange to get too far away from those. The thing
was originally designed as a rebuttal to certain theoretical arguments
from very LISP-literate people like RG and (to a lesser
extent) GLS. Considerable background was assumed.
Anyway, what revisions do you want me to make and what ones do you
want to do yourself? Anything that is intended to fit in the big
framework of the issue (such as the LAMBDA motivation) should be done
or at least laid out in detail by you, I think. I can do the mundane
stuff if you don't want to. Whatever.
******************************************************************
John, OK, msg of 1045PST (specifics) are mostly ok,
but I'd feel strange having "A common sort of function in LISP..."
be the first paragraph in my paper. If it were a chapter in a book,
then ok, but i'd like a little apparent independence, even if I am
willing to accept 90% of your suggestions (which I am). I was really
fond of the Abstract Data Types argument of chapter 1, but your version
of it in the intro was nice (and more succint). In general, I always
like to start and end on a Philosophical note (like a Scientific
American article).
Ok to incorporate necessary footnotes into text. Speaking of
footnotes, the Chapter 9 scheme goes way back. I just
implemented and extended the crude form of it which I got from (I think)
Hanan Samet, and which appears in my ref Steele&Sussman in
a footnote (Art of the Interpreter, note "This Ain't Alists").
I wanted to reference the original source of the idea, thinking it
was them, but removed the ref when I realized it was probably older.
In any event, I only extended it slightly and pointed out how neat it
is for CLOSURE's.)
Re CLOSURE, do you motivate deep vs. shallow binding in the intro
or elsewhere? I don't want to try to explain CLOSURE without that.
I agree with your comment on my use of the word "function".
It *is* ambiguous, but purposefully so; it refers to the abstract
entity or the linker node (1 or 4 in ch. 1's decomposition), but
*not* to 2 or 3 (the abstract and concrete algorithms).
Will the folks at BYTE redraw my figures? Maybe you or someone
can XGP them (I used the GRAFIX font like you use in Anatomy,
but our printer has lousy resolution).
Maybe a less complicated example in ch's 5 and 6; the DEFUN
example is a "wow" example. It really wasn't appropriate, but
I felt I needed something to motivate being able to pass fexpr's
around like that.
Oh well, have fun.
- Phil Agre
∂04-Mar-79 1135 PEAGRE at MIT-MC (Philip E. Agre) bindings &c.
Date: 4 MAR 1979 1435-EST
From: PEAGRE at MIT-MC (Philip E. Agre)
Subject: bindings &c.
To: jra at SU-AI
John, If you can think of a cute way to explain closures, more
power to you. I misspoke a bit, one needs static/dynamic to
understand closures (or so I meant to say in last msg), but
one needs deep/shallow to understand their implementation.
Compare my implementation of CLOSURE's in deep binding
system with Greenblatt's in shallow binding system. His is gross,
mine is efficient. In general, this is because Depp binding
supports context-change sorts of things, while shallow binding gives
one raw speed in non-fancy situations (although I don't really
even believe that...) In any event, the best solution is GLS's
in his Master's thesis, which is a real winning document.
∂20-OCT-76 0944 RPG
∂20-OCT-76 0403 JRA LISP
WHAT ARE YOUR FIRST IMPRESSIONS OF MANUSCRIPT? AND HOW FAR ALONG
ARE YOU? IF YOU WANT MORE, THE NEXT CHAPTER IS ALMOST READY.
JOHN
I am pretty much through chapter 2 (reading it fairly
carefully though), and have found some passages somewhat difficult
to understand (difficult in spite of the fact that I understand
what you are trying to get at). In particular, there is the section
on strictness/non-strictness/divergence etc. I have no specific complaints
about it , but I felt uncomfortable reading it the first time. I'm also
not too sure about the real advantage to the t/f vs. T/NIL decision. In some
sense, I view the ambiguity on LISP as one of its features.
I can take the next chapter whenever you are ready. I am planning
to really gung-ho it this weekend and be able to give back the commented
version I am reading.
-rpg-
∂25-OCT-76 1043 RPG
∂25-OCT-76 0358 JRA maclisp listing
the last listing i caught was about 6.5 pounds; that was pre-bibop:1972.
if you can tell me where the file(s) exist, i can list them early in the
morning.
john
ok, the source will appear in 1,rpg by Oct 26. it will be called
lisp.nnn where nnn is something like 232.
I am 3/4 done reading the parts i have and hope to finish tonight.
-rpg-
∂25-OCT-76 1509 RPG MACLISP
WELL, JONL AND I ARE NOW TRYING TO FLUSH THE NON-BIBOP CODE,
SO IT IS NOT IN A GOOD STATE TO LOOK AT.
-RPG-
∂28-Oct-76 2107 RPG BOOK
I have finished the first part of the book and have the following
general comments:
The parts on data structuring seemed to me to be forced. It may
be that I have some residual bigotry on my part, but I felt that it
didn't roll to easily.
On the other hand, I felt that the sections on EVALuation and
spaghetti were among the best I have read in that area (i.e. excellent).
The implementations were quite understandable and the points were well
made.
More specifically, the comparison or analogy between mathematical
definitions and data structuring appeared to be very unnatural, although
I felt that the points made were good.
On spaghetti, my feeling is that it is undoubtedly something for
people who use LISP should know about, but it may not be something that
is ever useful in practice. I have personally never known anyone who has
used it in anything like a production program (except me), and almost none
who have even used it except to see how it works. It seems that there is
always a better way to achieve ones ends than by a general purpose &
inefficient features. Spaghetti invariably saves too much information, tends
to favor lexical variables (especially when you usually want fluid), and forces
laziness on the part of the hacker. For instance, I wrote a hairy pattern
matcher once which required real bactracking in a car/cdr recursion (not a
simple tree search). The matcher often had to bactrack into a control frame
that had been exited. Well, in LISP370 I used spaghetti, and in MACLISP I
explicitly used continuations, which clarified control and was fairly efficient
through the compiler. (the idea was to make the cdr recursion a sub-computation
of the car recursion as opposed to a sister computation). I plan to recode
the LISP370 version soon.
Another point concerns the use of continuations in the book. It
seems that they only appear briefly, as a passing concept between recursion/
subroutine returns and PC control. Well, either continuations should be
presented as a programming skill on its own, or it should be flushed as
a puzzling interlude, or some comment might be derived about its intermediary
position wrt stack control style and Program Counter style.
I am always puzzled about the use of a "LISP Metalanguage" which is
separate from the S-expression notation. I am not questioning the usefullness
of the metalanguage as a theoretical tool of great importance, but the
of it as a pedagogical tool. When I TAed 206 for McCarthy, I saw the
bewilderment it caused when the two notations were introduced in parallel.
A point this "algolishness" seems to obscure is the natural ambiguity inherent
in LISP, namely between the program and the data. Now, I am definitely
not trying to say that it is the ability of LISP to write programs and execute
them which makes i such a nifty language, but that the ability to cons up
certain restricted expressions which can be later applied on a small scale
(that is the handles on the evaluator) that make it a useful language.
A point that you don't seem to make is that LISP is an environment that
the user can sit inside of while his programs suffer trauma, and not a
compiler-based language in which you create your poooooor program, and boot
it into the confusing world of the compiler, tto suffer alone in the cruel
world.
I guess LISP is naturally a hacker's programming language, in that
every nifty hook is available, and you can either hang yourself or not
according to your own abilities.
An important aspect of any comprehensive discussion of LISP is why
it is that such an obscure looking language should be preferred by AI
hackers.
Well, I look forward to the next sections of the book, and will
put the commented first part in your mailbox, if you have one, or mine.
-rpg-
∂10-Nov-76 1351 RPG PROGV Feature
To: MACLSP.DIS[AID,RPG]:;
Here is a little known feature of Maclisp that may be of some
use:
(PROGV <VAR-LIST> <VALUE-LIST> <FORM1> <FORM2> ... <FORMN>)
EVALUATES <FORM1> ... <FORMN> AS A PROGN IN AN ENVIRONMENT
CREATED BY BINDING THE SYMBOLS IN <VAR-LIST> TO THE
RESPECTIVE VALUES IN <VALUE-LIST>. THAT IS, THE FIRST
TWO ARGUMENTS TO PROGV ARE EVALUATED; THE FIRST MUST
PRODUCE A LIST OF SPECIAL VARIABLES, AND THE SECOND
A LIST OF VALUES. THE VARIABLES ARE THEN BOUND TO THE
VALUES. IF TOO FEW VALUES ARE SUPPLIED, THE REST OF
THE VARIABLES ARE BOUND TO NIL. IF TOO MANY VALUES
ARE SUPPLIED, THE EXCESS VALUES ARE IGNORED.
THE BODY OF THE PROGV IS THEN EVALUATED AS A PROGN,
THE VARIABLES UNBOUND TO THEIR OLD VALUES, AND THE
VALUE OF THE LAST FORM IS RETURNED.
EXAMPLE:
(SETQ A 'FOO)
(SETQ B 'BAR)
(PROGV (LIST A B 'B) (LIST B) (LIST A B FOO BAR))
==> (FOO NIL BAR NIL)
∂10-Nov-76 1622 RPG Book
The static structure section is in my box.
I did not find it as well wriiten as the evaluator sections.
In particular the treatment of shallow binding was
misleading/incomplete.
-rpg-
∂11-Dec-78 1724 RPG NEWIO programming tips
To: "@MACLSP.DIS[AID,RPG]" at SU-AI
When compiling a file, if you want to do a require, just say:
(REQUIRE ...)
rather than the older:
(DECLARE (REQUIRE ...))
or whatever. NCOMPLR knows about REQUIRE.
The useful feature EVAL-WHEN can be used to do things in the compiler
environment much like a DECLARE:
(EVAL-WHEN (COMPILE) (DEFUN ZTESCH MACRO ...))
You can also have LOAD and EVAL appear in the options part as well as
the COMPILE. If EVAL and LOAD appear then the form will be EVALed at LOAD time.
(EVAL-WHEN (COMPILE) (DEFUN FOO MACRO (X) 'FOO))
is totally equivalent to
(DECLARE (DEFUN FOO MACRO (X) 'FOO))
and
(EVAL-WHEN (EVAL COMPILE) P1 P2 . . . PN)
is equivalend to
(DECLARE (EVAL (READ)))
(PROGN P1 P2 . . . PN)
finally, one wants a way to cause something to happen during loading
of the compiled code - that is what the LOAD options is.
(EVAL-WHEN (LOAD EVAL) (PRINT 'LOADING-MY-SYSTEM))
∂21-Dec-78 1219 RPG Bug fix in NEWIO
To: "@USERS.DIS[AID,RPG]" at SU-AI
A bug wherein part of the LISP reader believed itself to be
in linemode and part in character has been patched using partial
knowledge. This means that the patch may or may not work, and even
might cause further bugs. Things which could conceivably be effected
are input from non-data-disk/datamedia terminals, programs using
tyipeek, and some kinds of disk IO. Symptoms of further lossage could include
waiting for input when there shouldn't be any, reading too much stuff, etc.
-rpg-
∂22-Dec-78 1630 RPG DEFUN change.
To: "@USERS.DIS[AID,RPG]" at SU-AI
The first atom in a DEFUN is ALWAYS interpreted as the name of the function.
So in (DEFUN FEXPR MACRO ...) FEXPR is the name of the MACRO being defined.
-rpg-
∂09-Jan-79 1542 RPG MacLisp matcher
To: "@USERS.DIS[AID,RPG]" at SU-AI
Here's some changes to %MATCH you matcher fans:
;;;;;;;;;; the matching function ;;;;;;;;;;
;;;
;;; (arg 1) - p - pattern
;;; (arg 2) - d - data
;;; (arg 3) - alist - optional list of variables (* or ?) whose values
;;; are to be retained during the match, much like the
;;; = variables below.
;;; elements of a pattern:
;;; ? - matches anything
;;; * - matches one or more expressions
;;; ?<atom> - like "?", but sets ?<atom> to thing matched
;;; *<atom> - like "*", but sets *<atom> to list of things matched
;;; =<atom> - matched against value of <atom>
;;; (restrict <one of above ?-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil
;;; $r, ⊗r - same as RESTRICT
;;; (restrict <one of above *-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil when given the list
;;; that is being considered for that variable as its argument
;;; (irestrict <one of above *-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil when given each element of the list
;;; that is being considered for that variable as its argument
;;; (done incrementally). So %MATCH will apply these predicates as
;;; it scans the input.
;;; $ir,⊗ir - same as irestrict
;;;
;;; (%match p d <variables to retain>) attempts to match p against d
;;; (%continue-match p d <variables to retain>) attempts to get the next
;;; possible match between p and d (by different *-variable
;;; bindings.
;;*PAGE
∂17-Jan-79 1546 RPG UTIL.>
To: "@USERS.DIS[AID,RPG]" at SU-AI
To speed up compilation (and interpretation), you might try changing your
(require util 1 dsk (aid rpg)) to
(declare (fasload '((dsk (aid rpg)) util fas)))
-rpg-
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂07-Feb-77 1207 HJS via NBST Urmi
John,
Thanks for sending Jaak Urmi's paper. I read it and it is a very
good explanation of shallow binding. I have made
modifications to it and other shallow binding schemes to handle the SETQ
anomaly we discussed. After reading Urmi's paper I feel that
Henry Baker's shallow binding scheme is identical to Urmi's
shallow surfaces. The only difference is that Urmi does not
require all variable to be bound at each new environment (i.e. newly
bound). Is Urmi's paper being published anywhere? Let me know
if you have any answers and if you agree with my
analysis. He also explains Greenblatt's scheme quite well.
Earlier I told you that you should check for QUOTE in your
EVAL in one of the earlier chapters. At the risk of
being put down again I repeat it. You can't do
if isconst(exp) then exp
and expect QUOTE to be handled properly since you want
if isquote(exp) then second(exp)
Other comments will be in the mail in the form of
pencil scratchings on copies of the manuscript. When will the
remaining chapters arrive?
How on earth did you ever figure out Wegbreit's paper on
"Retrieval from Context Trees" in Information Processing Letters.
I understand your explanation but can't figure out his "depth"
argument. Help?
Hope everything is OK. Will try to write up shallow binding stuff and send
to you. Regards.
Hanan,
∂14-JAN-76 1318 FTP: host HARV
***** FTP mail from [7100,133] (PRENNER)
john-
the user level of my lisp simpley had primitives
environ , enveval and setenv. they were essentially as
described in ben and dannys paper. i have some unreadable
lecture notes and some diagrams of the structures used, but
no formal documentation of the system exists.
the major implementation trick that i used was to use a
separate stack for the primitieves to execute on when they
were modifying the lisp stacks . this helped clarify the
coding immmensely. would be happy to
talk about it anytime.
chuck prenner (prenner @harv 10)
∂24-Jan-79 2120 MCGUIRE at USC-ECL August BYTE a possible paper
Date: 24 JAN 1979 2118-PST
From: MCGUIRE at USC-ECL
Subject: August BYTE a possible paper
To: JRA at SAIL
Dear Sirs,
Dr. Martin Griss and I have written a paper describing a
pseudo-code implementation of LISP. The p-code interpreter is written
in a portable language (BIL), which is based on Harrison's BALM work.
We have several different compilers for this language, to produce
FORTRAN code ( for the DECsystem-20,Data General Ecllipse,CDC-7600,
and Cray-1) and assembly code ( for the Z-80 ,with a PDP-11 version
underway). We have a draft of this paper available if you are interested.
Sincerely yours,
Gerald Q. Maguire Jr.
Net addresses:
MCGUIRE@ECL
or
Griss@ECL
Mailing address:
Computer Science Dept.
University of Utah
Salt Lake City,Utah 84112
Phone: (801) 581-6542
-------
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂22-DEC-75 0127 FTP:GLS at MIT-AI
Date: 22 DEC 1975 0426-EST
From: GLS at MIT-AI
To: JRA at SU-AI
I would like very much to read a copy of your book.
If you are interested in a poem, might I suggest
TGQ;TREE POEM @ MIT-ML ? Or maybe I will be inspired by reading
the book. I've not done too much about GC lately,
but be it known that I and Sussman have been hacking
with a new LISP-like interpreter, worrying about
implementation and semantics. You might try reading
GJS;SCHDOC MEMO @ MIT-AI (it is in XGP form -- the TJ6 source
is GJS;SCHDOC >).
-------
∂23-DEC-75 1117 FTP:GLS at MIT-AI
Date: 23 DEC 1975 1415-EST
From: GLS at MIT-AI
To: jra at SU-AI
Okay, my address is:
Guy L. Steele Jr.
MIT Project MAC
Room 834
545 Technology Square
Cambridge, Mass 02139
Thanks muchly for opportunity to see wonderful new lisp book.
-- Guy
-------
∂30-DEC-75 0556 FTP:GLS at MIT-ML
Date: 30 DEC 1975 0856-EST
From: GLS at MIT-ML
Subject: LISP MACHINE
To: JRA at SU-AI
WELL, GREENBLATT HAS BEEN OUT OF TOWN FOR A COUPLE OF WEEKS
FOR THE HOLIDAYS, AND BEFORE THAT HE HAS BEEN HACKING THE
CHESS MACHINE MOSTLY. I HAVE SEEN THE LISP MACHINE PERFORM
BYTE DEPOSITS, ETC. (I.E. THE MICROCODE WORKS), BUT I'M
NOT SURE IF THE MAIN MEMORY HAS BEEN HOOKED UP YET. ALSO IT
HAS NO PERIPHERALS RIGHT NOW -- IT HANGS OFF A PDP-11, WHICH
IN TURN IS INTERFACED TO MIT-AI PDP-10.
-------
∂01-JAN-76 0639 FTP:GLS at MIT-ML
Date: 1 JAN 1976 0940-EST
From: GLS at MIT-ML
To: JRA at SU-AI
BOOK ARRIVED YESTERDAY IN FINE CONDITION. I WILL GUARD IT
WITH MY LIFE FROM XEROX MACHINES. IT IS INDEED ALREADY QUITE
BIG -- I WOULD SUGGEST THAT YOU PUT DATA BASES, ETC. IN VOLUME 2.
I'VE NOT READ MORE THAN A FEW PAGES; YOU'LL PROBABLY HEAR MORE
FROM ME AS I PROGRESS. JUST GLANCING THROUGH IT THOUGH, IT LOOKS
LIKE THE BOOK I'VE BEEN WAITING FOR YEARS TO SEE. HAVE A HAPPY
NEW YEAR.
-- GUY
-------
∂19-JAN-76 1220 FTP:GLS at MIT-ML
Date: 19 JAN 1976 1519-EST
From: GLS at MIT-ML
To: JRA at SU-AI
I HAVE BEEN SLOWLY BUT SURELY PLOWING THROUGH THE BOOK.
RIGHT NOW I'VE ABOUT FINISHED CHAPTER 2, BUT MY PACE SHOULD
ACCELERATE NOW THAT MID-JANUARY PWE EXAMS ARE OVER.
I THINK THE APPROACH IS INTERESTING, BUT THERE ARE SOME BUGS.
I'VE LOST YOUR MAILING ADDRESS, SO IF YOU'LL ARPA-MAIL IT
TO ME, I'LL MAIL YOU BACK THE PAGES CHAPTER BY CHAPTER,
WITH TYPOGRAPHICAL CORRECTIONS AND AMUSING COMMENTARY BY
YOURS TRULY.
BY THE WAY, MACRAKIS TELLS ME YOU'LL BE SENDING HIM A COPY?
(GOOD LUCK, HE WILL BITCH EVEN WORSE THAN I WILL.)
-------
∂12-FEB-76 0845 FTP:GLS at MIT-AI
Date: 12 FEB 1976 1143-EST
From: GLS at MIT-AI
To: jra at SU-AI
Be not discouraged. I intend fully to review the entire book.
As I said, I have hope that the last half will be much better.
I'm sorry if I seemed harsh in my letter. I will be quiet busy
for the next couple of weeks, but I think I can certainly mail
you reviewed chapters at the rate of one every three or four weeks
at worst. Would that be sufficiently fast for your purposes?
-------
∂12-FEB-76 0902 FTP:GLS at MIT-AI
Date: 12 FEB 1976 1200-EST
From: GLS at MIT-AI
To: jra at SU-AI
Well, now that I have a better idea of your audience,
I can do a better job of reviewing, I guess.
Maybe what mislead me was the title: "The Anatomy of LISP"
looks like it means a book about LISP. Maybe you want
something like "Computer Science: a LISP Approach",
except that that sounds like a tired cliche. "The Anatomy
of LISP" is a great title -- it's just that it's not
precisely what the book is about, in some sense.
But maybe I am picking nits.
I suppose that m-expressions are okay. I still say they are
hard to read. Maybe if you had a better font, and pretyy-printed them
better. I hope the printers have a good font. The major problems are
that the semicolons are italic, and would look better if vertaical;
and that the square brackets don't have enough space between them,
so they're hard to count.
While you may not want to use "top", I think it is still true that
one shouldn't confuse errors with non-termination. I don't see
how coalesced sums can possibly hurt you. Another way is to use
"super-bottom" and "super-top"; i.e., every domain has its own
bottom and top, and there is a special bottom below all other
bottoms, and similarly tops. But it is very confusing
to say that bottom means "undefined", and later to say "[43 -> x; y]
isn't 'bottom' -- it's *really* undefined".
-------
∂03-Mar-77 1603 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) Knight displays
Date: 3 MAR 1977 1904-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
Subject: Knight displays
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].70877>
Well, a Knight display terminal consists of a TV monitor and
a separate keyboard (made by Microswitch). The TV gives something
like 450 by 380 raster (i forget exact figures); using a 6x12
character matrix, this gives 96 chars wide and 37 or so lines.
The TV screen is repetitively refreshed on a bit basis from
a memory.
There are far more terminals than can be used at once - they are cheap
enough to have one in every office, naturally. There are
14 "video buffers" of 16K 16-bit words apiece (room for
expansion to 16 buffers). There is a crossbar (the video switch)
which connects bit sources to bit sinks (16x32). Currently
the only sources are the video buffers, and sinks include all
the terminals and a Tektronix copier.
The video buffers hang off a unibus interface on a PDP-11.
A register controls which one is accessible to the unibus
(the PDP-11 also has 12K of normal memory). The PDP-11 in turn
hangs off the MIT-AI pdp-10 to pdp-11 inteface, which makes
PDP-11 memory addressable from the PDP-10. In this way
a user program, after making a number of system calls, can
write directly into the bits of the TV screen:
the user memory refeence is mapped by the paging box to a magic
address in high memory (location 2,,xxxxxx); the 10-11 interface
maps it to the correct PDP-11; the unibus interface maps it
to the correct TV buffer; and voila!
The unibus interface for the buffers has an ALU inside of it
which is sometimes useful; it can do an IORM faster for you
than the PDP-10 can.
The kayboards are similar to Stanford keyboards,
but I think have a few more keys. They generate 15 bits
(64 code-generating keys @ 6 bits, shift lock, and left/right
each of ctrl/meta/top/shift). The PDP-11 immediately folds this to 12
bits (top,shift lock, shift, meta, ctrl, and 7 bits of ascii)
and passes it to the PDP-10. User programs can read them
in 12-bit or 7-bit mode. User programs that read 12 bits
conventionally fold them down to 9 bits (meta, ctrl, ascii)
though they don't have to.
that answerthe question? if not, tk@ai himself can probably helpp more.
-- Guy
∂01-Feb-78 1057 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) last message
Date: 1 FEB 1978 1356-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: last message
To: JRA at SU-AI
CC: GLS at MIT-AI, (BUG LISPM) at MIT-AI
please, please. i'd like to know how to get information about
lisp machine, perhaps including lisp source.
john
Sorry. The best thing to do is contact the LISP Machine Group
(BUG-LISPM @ MIT-AI). The LISP Machine code lives
on various directories such as LISPM, LISPM1, and LMDOC
at MIT-AI, but you will probably have a hard time wading around
in it without guidance from wizards.
∂25-Jan-79 1821 GLS LISP etc.
To: JRA at SU-AI
CC: GLS at SU-AI
Unfortunately I will be immensely busy during the next month or two,
and don't eally have the time to write an article for BYTE in the
near future, much as I would like to. An AI memo should come out
fairly soon concerning the LISP chip, and a shorter paper is appearing
in the proceedings of the Caltech conference on VLSI which I just now
got back from. I'll be sure to send you a copy. I got a copy of your
book from McGraw-Hill, and it looks pretty good. Thanks for the
warm acknowledgement in the preface. Are you still at HP, or what
are you doing?
-- Guy
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂19-MAR-76 0150 HPM
Thanks for the note.
The ideas i briefly dumped on you a year ago have evolved much and
have become an obsession. Am in the process of writing up a synopsis,
to be complete by the end of the month, and you get a copy. Essential
idea is a moby (10↑3 to 10↑6 machines) multiprocessor interconnected
by Batcher sorting nets, which offer crossbar equivalence at n*(log(n))↑2
cost. Some programming languages (including LISP) and operating systems
for it vaguely defined, with some clear spots.
Yes I am interested in a copy of your text, if you can spare one. Knowing
my failings, though, I won't promise to generate many helpful comments.
∂27-Feb-78 1706 HPM more video
1. the xgp-to-gray sacle algorithm ( i know you told me once, but
(blush, blush) i forgot.
2. given the gray scale channels, how much smoothing does the
video synthesizer do.
*******
imagine a page of XGP output. It is 8 1/2 by 11 inches and has 200
dots per linear inch in each direction, each dot being black or white.
Call a black dot a 1 and a white spot a 0. The page is then an array
of 2200 rows and 1700 columns of bits.
Each data disc channel is conceptually organized into 480 rows and 512
columns of bits. There are 32 of these channels altogether, all producing
bits simultaneously. Normally they are used to operate 32 different tv
screens, each a 480 by 512 by one bit display. Eight of these channels go
to a digital to analog converter. This D/A is thus provided with eight
bits for each of the 480x512 points on a TV screen. It takes these
8 bits and translates them to one of 2↑8 grey level values. Thus the
output of the D/A is a tv image with 480x512 samples, each one of 2↑8
shades of grey. The data-disc:D/A converter is called the video
synthesizer. There is no additional smoothing except perhaps that
caused by the limited frequency response of the video amplifiers
anlong the way to your TV screen, and by the finite spot size of
the electron beam in your CRT.
The XGP dot array is more than three times as wide the data disc
array, and more than four times as tall. Also, the TV screens are
wider than they are tall, making them just about right for displaying
a half page of XGP output. A half page is still over 3 times as wide
and 2 times as tall as the DD array. By throwing away some of the
(hopefully) blank border on the page, the ratios are made exactly
3 and 2. So now imagine that each DD dot must somehow represent
a little 3 by 2 subarray of the XGP array. If we sum up the number
of 1's in each of these subarrays, we get numbers from 0 to 6.
If 0 represents white and 6 represents black, with the numbers
in between representing proportional shades of grey, we can display
the resulting pattern on the video synthesizer. It looks like
a blurred version of the XGP page. That's half density XGPSYN.
Full density turns the page on its side and compresses the
page length by a factor of 4 (instead of 2) and the width by
3, as for half density. Double density does 4 lengthwise and
6 sideways (giving numbers from 0 through 24).
The simple summing over subrectangles is a filtering. Other
more complicated filtering algorithms, that involve shading some
adjacent dots, might give even better results [CACM V20 #11 799:805].
*******
3. where, oh where, might i find the video synthesizer details
and even perhaps the xgp synthesizer listings?
*******
The source for XGPSYN is XGPSYN.SAI[PIX,HPM], though I don't think
it will be too helpful.
*******
these and other questions can only be answered by YOU.
besides, the gratitude of the huddled masses, I'd even autograph
a copy of my forthcoming (and outgoing) LISP book.
*******
wow!
*******
i await pregnantly,
john
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂29-Oct-76 1101 RPG GRIND
To: MACLSP.DIS[AID,RPG]:;
The MACLISP grinder now understands E-files. Grinding an E format
file will cause the directory to be flushed.
-rpg-
∂29-Oct-76 1824 RPG BIBOPIZATION
To: MACLSP.DIS[AID,RPG]:;
MACLSP is now fully BIBOPized and SAIL housebroken.
MACLSP, NCOMPLR, & SCHEME all run under BIBOP; MACLSP IO routines
understand E-format files. This includes NCOMPLR and the GRINDer.
Don't forget to use EREAD in place of UREAD for all normal disk IO.
(This is the routine that understands E.)
-rpg-
∂01-Nov-76 2201 RPG BIBOP
To: MACLSP.DIS[AID,RPG]:;
Don't forget, R MACLSP invokes the latest BIBOP version
of MACLISP.
-rpg-
∂14-Dec-76 2221 RPG Printing windows/SAIL
To: MACLSP.DIS[AID,RPG]:;
One can now print the window surrounding a CE by
saying "W" to the Editor. If the windowsize is 2, then the
2 tokens preceeding the CE, the CE, and the 2 tokens following
the CE are printed (a token is an expression or a parenthesis).
The windowsize is set by (WINDOW n).
∂09-Jun-77 1415 RPG sewer OLDIO
To: MACLSP.DIS[AID,RPG]:;
At SAIL Maclisp has been modified as follows: ordinary disk file
IO now uses 6 buffers in the input (output) buffer rings and fasload reads
1400(8) words at a time from disk in dump mode while fasloading. Since the
bottleneck at SAIL is the disk right now these changes will greatly
improve the performance of Maclisp AND the rest of the lusers on the
SAIL machine. However, there are a few things to watch out for:
1. the correctness of Require in this new scheme has not been proven.
2. BPS will need to be increased for fasload. Essentially fasload
uses array space for its dump mode buffering. So, the increased size
(200 to 1400 (8)) means that BPS should be about 1200(8) [640.] words larger
than before. You ought to go through your *.ini files and make this
update or face "no core -- array" errors.
-rpg-
∂10-Jun-77 1145 JP E - MACLSP - E
To: MACLSP.DIS[AID,RPG]:;
ET.FAS[MAC,LSP] has been modified so ⊗XRUNning from E returns you
to the calling MACLSP image. LSUBR ET now returns nil. Comments → JP
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂23-FEB-76 1503 FTP: host HARV
***** FTP mail from [7101,422] (HOWARD)
JOHN:
I FINISHED TRANSFERING THE FILES. YOU WILL FIND (I HOPE) THE
FOLLOWING ON YOUR DIRECTORIES:
BUILDL.DOC LMAN.DOC EDIT1.DOC EDIT2.DOC MI.DOC GUTS.DOC
AUXFNS SVLISP HACK TRACE EDIT BT
SPARM.M11 LGLOB.M11 MACRO.M11 DSTUF.M11 ATDAT.M11
E SUBR.M11 SUBRCOM.M11 EARLY.M11 SYSS.M11 GCOL.M11 NOW.M11 FP.M11
SYSEND.M11 PROB7.M11 PROB8.M11 PROB8.ORI PRO
CTABLE.M11 PROBEND FILLER.M11 NOROOM.M11
MI.TEC
SHRLISP
THE USER'S MANUAL IS LMAN.DOC... BUILDLISP.DOC TELLS HOW TO MAKE A LISP
FROM SCRATCH. GUTS.DOC DESCRIBS THE INTERNALS OF THE LISP SYSTEM.
THE EDIT FILES ARE FOR THE IN-CORE EDITOR THAT NO-ONE
USES SINCE WE'VE PUT IN (TECO 'FILE) AND (TECF(FUNC1 ... FUCN)).
THE SECOND GROUP IS THE LIBRARY. AUXFNS IS PRE-LOADED, WITH HACK AND SVLISP. THE OTHER'S ARE LOADED BY THE USER WHEN HE WISHES.
THE THIRD GROUP IS THE SOURCE FOR LISP. THE FILE MI.TEC IS A OFTEN USED
MACRO FOR LIST STRUCTURE INSERTION . THE FILE SHRLISP IS TEHE UNIX
CCL FILE TO MAKE A LISP.
I HOPE THAT THIS IS WHAT YOU NEED. IF THERE IS ANY OTHER PART
OF UNIX LISP THAT YOU WANT TO GET AHOLD OF, LET ME KNOW.
FORREST HOWARD
(PS PLEASE LET ME KNOW IF YOU GIVE A COPY OF LISP TO ANYONE ELSE.
YOU'RE WELCOME TO DO SO, BUT I'D LIKE TO KEEP TRACK OF WHERE
IT LIVES.)
FORREST W. HOWARD JR.
CENTER FOR RESEARCH IN COMPUTING TECHNOLOGY
AIKEN COMPUTATION LAB
HARVARD UNIVERSIT
CAMBRIDGE, MA. 02138
GOOD LUCK
FORREST
∂09-MAR-76 1311 FTP:HOWARD at HARV-10 LISP/BOOK
Date: 9 Mar 1976 1610-Edt
From: HOWARD at HARV-10
Subject: LISP/BOOK
To: JRA at SU-AI
JOHN:
SORRY I TOOK SO LONG TO GET BACK TO YOU. FIRST YOUR COMMENTS:
THE FRMPTR WAS A CELL I ADDED AT THE REQUEST OF AN UNDERGRAD
(JOHN BURRUS) THAT HE FELT NECESSARY TO IMPLEMENT SPAGETTI
STACKS. HOWEVER, THAT WAS LAST SPRING, AND JOHN HAS GONE FORTH
TO MAJOR IN ENGLISH. SPAGETTI STACKS ARE SOMETHING I'M PLANNING
EVENTUALLY (MAYBE LATE SUMMER).
XFER LISP IS THE PDP-10- UNIX ENVIRONMENT TRANSFER PROJECT, WHICH
I'M DOING TO JUSTIFY MY EXISTANCE THESE DAYS. WE'RE PLANNING
ON TRANSFERING A COMPLETE ENVIRONMENT (DATA AND CONTROL) TO THE
10 TO CONTINUE RUNNING WHEN WE'RE BLOCKED ON THE 1.( AT
THE MOMENT "BLOCKED" MEANS NO CORE, BUT WE EVENTUALLY HOPE TO DEVISE
ALGORITHIMS FOR THE MONITOR TO "TELL" LISP IT'S BLOCKED).
THE OBLIST SWITCHING IS SOMETHING I DID LAST SPRING WHEN TAKING
A COURSE AT MIT UNDER RON RIVEST. SEE THE CURRENT ACM FOR THE
SPECIFICS.. BASICALLY, IT A "MOVE TOWARDS THE FRONT" ALGORITHIM
TO SPEED UP OBLIST SEARCHING.
INDEED THIS IS CLOSE TO PRENNER'S LISP-- WHEN I ORIGINALLY WROTE AS AN UUNDERGRAD,
WE WE CONVERTING APPL. MATH [[0 (MACHINE LANGUAGE) TO UNIX FROM A 10, AND
WERE TRYING TO MAKE THE COURSES (AND PROBLEM SETS AND LISP)
AS IDENTICAL AS POSSIBLE.
I WILL BE INTERESTED IN SEEING THE BOOK... SOUNDS LIKE IT SHOULD BE GOOD
READING
TQAKE CARE
FORREST
I SHOULD MENTION THAT OTHER GOODIES ARE AVAILABLE FROM THE SAME
ADDRESS, INCLUDING TECO, RT-11 BASIC, A DDT, SOURCES FOR THE
ASSEMBLER AND LINKER, AND A PROGRAMMING LANGUAGE CALLED "PPL",
STANDING FOR POLYMORPHIC PROGRAMMING LANGUAGE. THESE ARE ALL ON
A BASIS SIMILAR TO LISP. ECL FOR THE 11 IS ALSO COMMING SOON.
OTHER GOODIEES ARE AVAILABLE FROM BERKELY (INGRESS, A DATA BASE
SYSTEM), COMMERCIAL UNION LEASING CO, NEW YORK (FORTRAN 4-PLUS ) (YECH!!)
AND THE NAVAL POST-GRADUATE SCHOOL (A DEBUGER AND OTHER STUFF). BELL IS
RUMORED TO BE WORKING ON ALGOL-68 COMPILERS.
3) YOUR BOOK WAS READ FOR THE SECOND TIME LAST SATURDAY. TYPO'S
I NOTICED WERE "ABRECIATION" FOR ABREVIATION (ABOUT PAGE 30)
(YOU MIGHT HAVE MEANT THIS) AND SEVERAL PLACES TOWARDS THE
BACK OF THE BOOK WHERE THE PABE NUMBERING WAS SCREWED UP
IN ITS TYPEOUT.
I RESPECT TO FORMAT, I FOUND THE BOOK FAIRLY INTERESTING.
THE SECTIONS THAT I MOST WANTED TO SEE (FUNARGS, SPAGETTI,
QUANATATIVE TRADEOFFS BETWEEN SM AND DEEP-BINDING) WERE ALL
"MORE ON ...." SECTIONS. THE REST OF IT SEEMS WELL THOUGHT OUT,
AND WELL PRESENTED.
I'M NOT SURE IF I AGREE WITH THE ADVOIDANCE OF NIL AND T,
AS WELL AS THE CONCEPT OF FIRST, SECOND, ...; IT SEEMS TO ME
THAT JUST AS THE PROGRAMMER IN ASSEMBLER KNOWS THAT A 0 IS
FALSE OR HALT, AND A 1 IS TRUE OR AN INSTRUCTION, THE LISP
USER SHOULD BE AWARE OF THE
DUALITY OF VARIOUS OBJECTS. THE NOTION OF FIRST&CO. WOULD SEEM
TO HELP CONFUSE THE HOPEFULLY CLEAR RELATIONSHIP BETWEEN LISTS
AND DOTTED-PAIRS.
THE OVERALL ORGINIZATION IS GOOD. THE IDEA OF PRESENTING LISP
MATHEMATICALLY FIRST, FOLLOWED BY THE ISSUES AND THEN A COMPILE
TO SEE HOW TO DO THINGS SEEMS REASONABLE.
I PROMISE TO READ A THIRD TIME, AND MAKE FULL COMENTS THEN.
ONE MORE THING, I'M LEAVING FOR PARIS ON JUNE 1, SO TRY
TO GET CORROSPENDENCE TO ME BY THEN. I PLAN TO LOG IN HERE ABOUT
ONCE EVERY 2 WEEKS (FROM THE LONDON TIP), SO POST THAT MAIL AND
YOU'LL EVENTUALLY GET AN ANSWER. AFTER OCTOBER I'LL BE WORKING FOR
COMMERCIAL UNION LEASING CO, 645 MADISON, NYC, 10022 (I THINK)
SO SNAIL-MAIL CAN GET ME THERE (I HOPE TO ALSO KEEP THIS ACCOUNT).
FORREST
∂24-MAY-76 1141 FTP: host HARV
***** FTP mail from [7101,422] (HOWARD)
JOHN:
A QUICK REPLY TO YOUR LETTER:
1) UNIX RUNS ON ANY 11 WITH SEGMENTATION (MEMORY MANAGEMANT UNIT) AND
EXTENDED INSTRUCTION SET (IF A 11/40 (THIS MEANS SOB, MUL, DIV)).
ONE BLOCK TYPE DEVICE IS REQUIRED (DECTAPE, RK DISK, RP DISK, ETC).
IT IS EXTREMLY FLEXIBLE IN THE CONFIGURATIONS THAT IT ACCEPTS; I
HAVE RUN UNICIES WITH ONE DECTAPE AS A "ROOT FILESYSTEM" AND SWAP
DEVICE, AND THE OTHER DECTAPE AS A "REMOVABLE FILESYSTEM".
THE BIGGER AND FASTER THE DISKS/TAPES THE BETTER, BUT ALMOST ANYTHING
WILL DO.
UNIX SUPPORTS ALMOST ANY PERHIPERAL MADE BY DEC, AND QUITE AFEW FOREIGN
PERHIPERALS (VOICE SYNTHESISERS, PHOTOTYPESETTERS, GOULD PRINTERS, ETC.).
OH YES -- YOU NEED MEMORY TO MANAGE. ABOUT 64 K WDS IS THE MINIMUM THAT I
WOULD CONSIDER, ALTHOUGH I'VE SEEN SMALLER.
2) RUMOR HAS IT THAT BELL HAS UNICIES TO RUN ON THE LSI-11 AND 11/20 OR
11/05. YOU'LL HAVE TO TALK TO THEM TO FIND OUT.
3) UNIX MAY BE CONVERABLE TO A DEC MONITOR. THE WAY DEC ORGANIZES THEIR
STACK-PROT
STACK/PROGRAM/DATA IS DIFFERENT THAN UNIX (DEC LIKES PROG HIGH IN CORE,
DATA IMMEDIATLY BELOW, STACK BELOW THAT. UNIX LIKES PROG LOW, DATA FOLLOWING AND
STACK STARTING AT -2 GROWING TOWARDS 0.) MAPING THE SYSTEM CALLS WILL BE FAIRLY
ESASY, AS I'VE TRIED TO (AT LEAST INITIALLY) TO LEAVE ALL THE
SYSTEM DEPENDENT STUFF IN ONE MODULE (THIS EFFORT HAS DETERIORATED OVER TIME).
AS A LAST RESORT, AL SPECTOR AT HARVARD WROTE A UNIX "MONITOR" THAT FITS
INTO A BARE MACHINE AND CAN BE USED TO HELP OUT WITH STUFF. AL WILL BE A
1-G AND STANFORD NEXT YEAR.
4) THE BIGGEST LOSS ABOUT USING UNIX LISP UNDER A DEC MONITOR OR 11-40 IS THE
LOSS OF I&D SPACE SEPERATION CAPABILITY. UNDER AN 11-45 OR EQUIVILANT, THE
USER HAS ABOUT 27.5 K OF DATA (NOT COUNING STACK) TO DO THINGS WITH.
THIS DROPS TO ABOUT 22K UNDER AN 11/40 OR NON-I&D MACHINE.
(P.S. ANOTHER ADVANTAGE OF I&D IS THE "FREENESS" OF NEW SUBRS OR FSUBRS.
THAT IS THE CODE FOR NEW SUBRS JUST POPS INTO I-SPACE, AND DSPACE REMAINS THE
SAME SIZE, WITH THE LANGUAGE BEING MORE POWERFUL AND/OR CONVENIENT.)
MORE ON THE BOOK TO COME. I GOTTA CODE RIGHT NOW, HOWEVER (I HEAR THAT
PLANE DRAWING CLOSE).
FORREST
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂02-May-78 1245 MG ML (LCF metelanguage)
To play with ML do "R ELCF" then when you get the LISP prompt
* do "(TML)" (u.c.) and then respond with <return> to both "THEORY?"
and "DRAFT?".e.g. simulated interaction:
.r elcf
*(TML)
LCF version 5 issued 27-oct-77
(with simultaneous substitution and new simplification)
THEORY?*
DRAFT?*
* .......
.........
..........etc.eg
.
.
.*letrec map fn l = null l => [] | (fn (hd l)).map fn (tl l));;..
----------------------------------------------------------
The ML prompt should be "#" but to do this needs (DE PROMPT (N) ...?...)
--eg see PROMPT[LCF,FWH] for the Edinburgh hack.
See yah....Mike
∂02-May-78 1258 MG erratum
"fn(hd l).map fn (tl l)" is more correct - ihad an extra bracket before
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂19-Jul-77 1436 JP
To: MACLSP.DIS[AID,RPG]:;
SAIL MACLSP interprocess communication
A preliminary version of a MACLISP interjob communication facility is
available to those of you lusers subscribing to the (help) autoload
facility. These functions permit arbitrary creation, deletion,
synchronization and intercommunication of MACLISP processes. For more
information read FASFRK.JP[LIB,LSP].
-j
∂06-Apr-78 1232 RPG New Maclsp
To: MACLSP.DIS[AID,RPG]:
Warning! LISP 1525 has been installed, the first new assembly
since September 1977. At the next opportunity you should re-make any
systems based on Maclisp as well as reassemble any LAP code which
does file IO. Also, you should READ LSPARC (the first 3-4 pages) to
learn of the changes in this version. Good luck.
-rpg-
∂07-Apr-78 1018 RPG *rset
To: MACLSP.DIS[AID,RPG]:
Remember, the default for *rset in MacLisp 1525 is t, not nil as
in all previous versions. Also, LISP.INI files, if present, are automatically
loaded.
-rpg-
∂07-Apr-78 1624 RPG Lisp 1525
To: MACLSP.DIS[AID,RPG]:
Compiled hunk code appears to lose in MacLisp 1525.
If this will effect you, use sys:maclsp.old.
-rpg-
∂07-Apr-78 1809 RPG Hunk bug in MacLisp 1525
To: MACLSP.DIS[AID,RPG]:
Re-compile all files which use hunks.
-rpg-
∂13-Jan-79 1005 Feigenbaum at SUMEX-AIM hp310
Date: 13 Jan 1979 1005-PST
From: Feigenbaum at SUMEX-AIM
Subject: hp310
To: jra at SU-AI
John, never heard of it. Sounds like someone put a lisp on an hp-300,
doesn't it? Anyway, if you find out more, let me know.
Ed
-------
∂01-MAR-76 1749 FTP:FEIGENBAUM at SUMEX-AIM book reviewers
Date: 1 MAR 1976 1749-PST
From: FEIGENBAUM at SUMEX-AIM
Subject: book reviewers
To: jra at SU-AI
everything is set. it is time for us to choose reviewers. Let us
talk by telephone and settle on something (someone;or plural).
please call. office or home (493-5618).
regardss, ed
-------
∂05-FEB-76 0941 FTP:FEIGENBAUM at SUMEX-AIM book review
Date: 5 FEB 1976 0940-PST
From: FEIGENBAUM at SUMEX-AIM
Subject: book review
To: jra at SU-AI
john, i am discussing the review situation this morning with
the new editor of the McGraw-Hill Computer Science Series, and
will get back to you today or tomorrow with news.
Regards, ed
-------
∂29-DEC-75 1251 FTP:ENGELMORE at SUMEX-AIM
Date: 29 DEC 1975 1243-PST
From: ENGELMORE at SUMEX-AIM
Subject: book
To: jra at SU-AI
john, sorry that i have not got back to you. i got the book and will
begin the editorial process shortly. things have been chaotic over the
holidats.....ed
-------
∂08-AUG-75 0927 network site SUMEX
Date: 8 AUG 1975 0927-PDT
From: FEIGENBAUM at SUMEX-AIM
Subject: book contract
To: jra at SU-AI
i talked with the cognizant mc-graw hill people about your contract.
your contract got engtangled in the question, "what market does it
fit into?" i had tried to answer that question for them in various
ways previously, but apparently there was a conflict between your
statement to them about this subject and mine...or somee other similar
confusion. in any eevent they will generate the promised contact soon
(for "contact" read "contract").i apologize for the confusion and the
delay.
your communications with others varies between the rational-academic-
colleagular mode and the angry-emotional mode. i have observed the
latter bexx but never experienced it personally until your last
message. that first experience was also hopefully the last.please
use only the former mode with me.
sincerely, ed feigenbaum
-------
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂03-Jan-79 0719 RWW
This course will be given. The time is 99% certain. The place is to be
determined. It starts Thursday Jan 4 and I will more info as to the place.
please feel free to call me and ask about it.
Title: Philosophy and AI
Winter Quarter
TTH 2:30 - 3:45
3 units
Instructor: Richard Weyhrauch
No Prerequisites. This course is for graduates and undergraduates with an
interest in AI. Text will consist of lecture notes and assigned readings.
Students will be expected to listen to the lectures, participate actively
in discussions and read the assigned readings. Course projects will be
available for anyone interested but they are not a requirement.
In this course I intend to address the question: what kind of thing should
a researcher in artificial intelligence be trying to build? I'll
introduce the idea of a "computer individual" (an electro-mechanical
associate) and ask what properties such an individual should have.
The course will have three parts.
In the first part you will be asked to suspend your judgement for a while
and learn some formal logic. This part of the course will be entirely
self contained and will not require any prior knowledge of logic. In fact
previous knowledge will probably get in your way for a while. There are
two purposes to this part of the course. The first is that the rest of
the course depends on your your technical understanding of the ideas I
will present. The second is that logic has been used only in a very
simple way in AI up to now and I hope to expand your perspective as to how
it might be used. To do this you need to know some technical things and
it is these I intend to teach. This will not be a logic course. It will
not cover the standard material in a logic course. It is a practical
course in building artificial intelligence systems. We will sometimes use
logic as a tool in way that it hasn't been used before. I hope to
substantially alter your view of what logic is good for. If I don't by
the end of this course I will consider it a failure. The points of logic
will be illustrated by the use of the FOL reasoning system, which embodies
these ideas.
The second part of the course will be taken up with relating the notions
of logic introduced in the first part to the question of building AI
systems capable of making intelligent conclusions from the data it has.
One section will be taken up with looking at problems that have been dealt
with using the McCarthy situation calculus style of representation. We
will introduce a new notion of situation and use blocks world problems as
an illustration of how to use this idea. We will work out D.Michie's keys
and boxes problem in detail. The discussion will include remarks about
STRIPS and SHRDLU. We will then use the meta-theoretical structures we
learned earlier in the course to explore the idea of machine learning and
problem solving in mathematical theory of computation. We will finish by
discussing reasoning about knowledge (one's own and other peoples),
"non-monotonic logic", and in general the problems of reasoning using
modalities. This is just a brief sketch of the topics that will be
mentioned. The purpose of this part of the course is to gain facility
with the use of the notions introduced at the start of the course and to
relate them to the kinds of reasoning systems that people currently find
interesting.
The third part of the course will directly address the question of
constructing electro-mechanical individuals - NOT the question of AI
programs. This shift of viewpoint will be central to our discussion of
the question: how is it that such a device can build a functional
understanding of his environment? This part of the course will discuss
many aspects of the problem of artificial cognition. I am interested in
several questions here. 1) how is perception possible, that is, how do we
get from sense impressions to theories of our world? In particular I view
natural language understanding as a perception problem, i.e., how do we
get from the stream of auditory input to an understanding of its meaning?
2) What is the origin of natural language? 3) What is a conversation? A
lot of this course will make remarks about the QUALITY of the conversation
we want to be able to have with our computer friend. In AI we talk about
common sense reasoning. I want to look at all of the above problems as
practical questions about what our common sense understanding of our world
is like and how we acquire and use it. These later questions will take us
far afield, with readings from psychology, philosophy, mysticism, politics,
etc.
In the end I hope that we will have had a good time exploring what a wide
range of contemorary ideas tell us about AI. In addition the technical
tools presented in my lectures are meant to describe practical and
implementable ways of embodying some of these ideas into an artificial
intelligence system.
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂05-Dec-78 0721 JFR via LCSR-TIP rumor
It isd true that I have a program which implements many of the features
of E on "standard" crt terminals (dm2500, dm1520, hp264x, adm3a,...).
This program is written in C and runs under the UNIX operating system.
Although we have been using it for 16 months, it should be regarded
as experimental.
∂05-Dec-78 0833 RG at MIT-AI (Richard Greenblatt)
Date: 5 DEC 1978 1135-EST
From: RG at MIT-AI (Richard Greenblatt)
To: JRA at SU-AI
NO RESPONSE INTENDED.. SOUNDS LIKE SORT OF AN INTERESTING
IDEA, BUT I SORT OF THINK IT WOULD MUDDY THE WATER TOO MUCH RIGHT
NOW. IN OTHER WORDS, I THINK WE SHOULD PROBABLY LET THAT SLEEPING
DOG LIE FOR A YEAR OR SO, IF POSSIBLE.
∂08-Jan-79 1338 STOUTE at MIT-MC (David Stoutemyer)
Date: 8 JAN 1979 1523-EST
From: STOUTE at MIT-MC (David Stoutemyer)
To: JRA at SU-AI
PETER MILNE TOLD ME THAT YOU ARE EDITING A SPECIAL ISSUE OF
BYTE, DEVOTED TO LISP. A COLLEAGUE OF MINE, AL RICH,
IMPLEMENTED A TINY LISP FOR THE 8080. IS IT TOO LATE
FOR HIM TO SUBMIT AN ARTICLE? IF NOT, COULD YOU TELL ME THE DEADLINES AND
THE EDITORIAL GUIDELINES?
REGARDS, DAVID STOUTEMYER, ELECTRICAL ENGINEERINGG DEPT.,
UNIVERSITY OF HAWAII, HONOLULU, HAWAII 96822
∂11-Jan-79 0857 PWM RANDOM
DO YOU KNOW ANYTHING ABOUT THE HP-310 LISP CALCULATOR THAT HP DEMONSTRATED
AT MIT THE OTHER DAY?
BY THE WAY THAT 8080 VERSION OF LISP USED STRUCTURE SHARING.
HAVE YOU HEARD ANYTHING ABOUT A HOME COMPUTER HP ARE GOING TO BE SELLING LATER
THIS YEAR - I THINK IT IS CALLED THE CAPRICORN OR SOMETHING LIKE THAT.
ACTUALLY TI ARE ABOUT TO COME OUT WITH SOMETHING TOO - SHOULD BE AM INTERESTING
YEAR.
PETER
∂15-Jan-79 0548 PEAGRE at MIT-MC (Philip E. Agre)
Date: 15 JAN 1979 0849-EST
From: PEAGRE at MIT-MC (Philip E. Agre)
To: JRA at SU-AI, CARL at MIT-AI
Re: August '79 BYTE (LISP)
I am in the process of preparing an article on the implementation
of functions in LISP, half philosophy-of-LISP, half assembly-language
coding hacks, which comes in 20- and 50- double-spaced-page versions.
It will appear this month (w/ luck) as a Univ. of Maryland Technical
Report under the title "Functions as Data Objects -- The Implementation
of Functions in LISP". Would you be interested in receiving a copy
of this report with an eye towards publishing it or a version of it
(e.g., the philosophy half or the hacking half) in the August '79
LISP issue of BYTE?
I can be reached within 2 days as PEAGRE@MIT-MC. I am an
undergraduate at the University of Maryland, hoping on doing AI
at MIT-AI starting in September. I would appreciate any consideration
you might give my material.
- Phil Agre
∂18-Jan-79 1732 PEAGRE at MIT-MC (Philip E. Agre) Byte Article (trials & tribs.)
Date: 18 JAN 1979 2032-EST
From: PEAGRE at MIT-MC (Philip E. Agre)
Subject: Byte Article (trials & tribs.)
To: jra at SU-AI
John-
I am thoroughly delighted by your interest in my paper
("Functions as Data Objects -- The Implementation of Functions
in LISP"). Right now it is being proofed by my expert staff
(Chuck Rieger, Hanan Samet, and co.) and should be ready
for TR printing by Wednesday. (Given our
publishing services here, this could mean one week or one month
until a really neat printing returns.) Anything on the high
side of that scale will cause me to slap a few custom copies
together within your required time parameters. As regards
a version of the paper suitable for publishing in BYTE,
I am just now paring the Tech Report down to a paper version.
Are you most interested in the philosophy-of-LISP parts, the
assembly-language-implementation parts, or the real-live basics.
Also, what prerequisites should I assume? I assume a LISP
tutorial will be the first-or-second article, so that I will
be able to editorialize and be understood. You say you will
be on SU-AI Saturday&Sunday; I would like to link to
you then to ask your responses to these and other questions
regarding the issue (such mundane things as "how long should
the article be", "how many articles will there be", "what
is the status of the project--is it definate that this thing
will occur?", etc.).
By the way, I have a list of typos from "Anatomy of LISP".
Would you like me to pass them along? (I am a great fan of
the book.)
Again, thanks for your interest and I will try to LINK
(w/ proper warning) to you this weekend.
Phil Agre (PEAGRE at MIT-MC)
∂21-Jan-79 1212 PEAGRE at MIT-MC (Philip E. Agre) Abstract of ''Functions as...'' (150 lines)
Date: 21 JAN 1979 1514-EST
From: PEAGRE at MIT-MC (Philip E. Agre)
Subject: Abstract of "Functions as..." (150 lines)
To: jra at SU-AI
John-
Following (if I understand :MAIL) is an abstract for my "Functions as
Data Objects..." paper and for all its various chapters. These
abstracts are for a not-totally-debugged version of the paper,
which has not been fully proofed. Also, this is the Tech. Report,
not the article. I would hope to put the whole thing in as an
article -- it runs 40 pages with 88 lines per page, 65 columns,
double spaced, including 13 figures and 5 pages of appendix,
as well as about 4 pages worth of inter-chapter paging-up.
I would appreciate any comments you might have (anything
from "I got it" to "Here is my opinion on all these subjects...").
In any event, I am working like mad to get a real-live copy
of the report out to you. Well, here it is...
Functions as Data Objects -- The Implementation of Functions in LISP
Philip Agre University of Maryland at College Park Jan '79
Global and Chapter Abstracts
January 21, 1979
Global Abstract: This paper discusses the manner in which functions are
defined and manipulated in various dialects of the LISP language. It
is argued that the syntax and mechanisms which are usually provided
for doing such things as passing functions as arguments and returning
them as values are unnecessarily inconsistent and clumsy. An alternative
scheme for implementing functions in LISP is presented. It is based
on the concept of a "linker node", a construct used in Wisconsin/
Maryland LISP, and allows great uniformity in the handling of different
types of functions. The advantages of being able to handle functions
in all the same ways as the other common data structures are demonstrated,
and one possible functions syntax is outlined and coded.
Chapter 1 - Introduction
(Abstract) It is a necessary and useful thing to treat "function" as
denoting an abstract data type with a well-defined set of construction
and selection functions. This is especially nice in LISP, where
a major point is made of equating programs and data. To treat this
topic further, we should make clear the distinction between external
and internal reprsentations of functions. For example, we might say
that the external representation is a representation of the abstractly
defined algorithm being implemented and the internal representation
(functional object) is a representation of the abstractly defined
function.
Chapter 2 - Traditional Implementations of LISP Functions
It is argued that most existing LISP implementations do not make
the necessary distinction between internal and external representations
and that this makes their "funarg" facilities clumsy to use.
The discussion concentrates on MacLISP.
Chapter 3 - A Notion of "Function as Data Object"
The "linker node" makes its debut. It is a two-word data object
whose first word is a subroutine-call instruction pointing at
an "expansion routine", one for each function type, e.g., expr,
fexpr. The second word points at various pieces of information
which the expansion routine will use, such as a LAMBDA-expression
or a FUNCTION environment. Linker nodes are created by "typing
functions", some of which (like LAMBDA) take s-expressions as
arguments and some of which (like FUNCTION) take other functions
as arguments.
Chapter 4 - A Possible Manifestation of the Scheme
A set of typing functions - LAMBDA, EXPR, FEXPR, MACRO, FUNCTION,
and LABEL - is defined in terms of what linker nodes they create
and how their expansion routines work. The various implementation
assumptions are presented and we get down to some assembly-language--
level coding. We finish by coding the EVAL function - 12 lines!
Chapter 5 - Some Examples and Consequences
A large, hairy-looking example is presented and de-mystified,
showing how many of the constructs work. Random mumblings about
efficiency.
Chapter 6 - Addition of Function Types
To show how easy it is to add new function types in this scheme (i.e.,
because of its modularity), the CLOSURE and TRACE types are defined
and coded.
Chapter 7 - Computing with Functions
It is argued that the ability to conveniently and uniformly pass
functions around can allow the programmer flexibility in program
design. The example which is pursued is that of computing with
functions. Familiar examples like COMPOSE and APL-like VECTORIZE
are seen to be easily definable. Others are efind, and examples are
presented.
Chapter 8 - What is Meant by "Referring to a Function"?
The various vexing problems of function naming and reference are
described. The LABEL construct is shown to be an elegant but
insufficient patch. A more general solution is described.
It is based on the idea of a "program module", is implemented
using cirular closures, and generalizes LABEL. However,
it too is shown not to be up to the task because of its dependence
on the deep binding mechanism.
Chapter 9 - How to Build an Association List
A really neat scheme for implementing the LISP deep-binding style
association list is presented, in which the alist is a list
of variable-list - value-list pairs. It is shown to provide
considerable space-savings and to generalize the "list of dotted
pairs" organization without much decrease in search speed. It
is this scheme which is assumed (by forward reference) by the
rest of the paper.
Chapter 10 - Conclusion
Summarization of major points.
Chapter 11 - Bibliography
Fairly sparse.
Chapter 12 - Appendix - A LISP Rendering of the Scheme
The set of typing functions described in the paper is implemented
in Maryland LISP. Some fairly elegant parallels between assembly
language and LISP are hidden within.
Fin
∂01-Feb-79 1642 PEAGRE at MIT-AI (Philip E. Agre) Functions as Data Objects (pant, pant...)
Date: 1 FEB 1979 1942-EST
From: PEAGRE at MIT-AI (Philip E. Agre)
Subject: Functions as Data Objects (pant, pant...)
To: jra at SU-AI
John,
In the (U.S.) mail to you is a draft of my paper "Functions as
Data Objects -- The Implementation of Functions in LISP". As it happens,
it is nearly identical to the final copy, which I am trying (against
all odds, be they bureaucratic or mechanical) to get off to the printers
to become a Maryland Tech Report. I would propose submitting a glossed
version of a selection of chapters from it as my contribution to your
upcoming special LISP issue of BYTE. The cover letter provides details.
I humbly ask your opinion of the paper, especially, do you think
it will be worth publishing? (It could be wrong for many reasons
besides its quality, for example its assumptions about the reader
or its esotericness.) In any event, I hope you enjoy it.
Phil Agre at Univ. of Maryland (PEAGRE at MIT-MC) or vice-versa.
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂15-Jan-79 2002 BAK at MIT-MC (William A. Kornfeld) Byte Magazine
Date: 15 JAN 1979 2258-EST
From: BAK at MIT-MC (William A. Kornfeld)
Subject: Byte Magazine
To: jra at SU-AI
I am finishing up a master's thsis on a pattern directed invocation
system implemented on top of Lisp (ala Planner, Conniver, etc.).
These languages make heavy use of list structure and would be a
good example of the extensibility of Lisp. I would be interested
in writing an article on what pattern directed languages are, what
what they are used for, and how they can be implemented in Lisp.
--Bill
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂16-Jan-79 0924 LAASER at PARC-MAXC2 a copy of my thesis
Date: 16 JAN 1979 0926-PST
From: LAASER at PARC-MAXC2
Subject: a copy of my thesis
To: jra at SU-AI
I'll send you a copy. It's still in draft form and I want to incorporate certain
suggestions people have made which will make easier reading. Would you like a
current copy or wait until I can revise it?
Bill
-------
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂18-Jan-79 1954 BAKER at MIT-AI (Henry G. Baker, Jr.) Lisp, etc.
Date: 18 JAN 1979 2254-EST
From: BAKER at MIT-AI (Henry G. Baker, Jr.)
Subject: Lisp, etc.
To: CARL at MIT-AI, jra at SU-AI
CC: BAKER at MIT-AI
I'd love to submit an article on (what else?) garbage collection!
What's the scoop?
∂21-Jan-79 2044 BAKER at MIT-AI (Henry G. Baker, Jr.) Lisp article
Date: 21 JAN 1979 2339-EST
From: BAKER at MIT-AI (Henry G. Baker, Jr.)
Subject: Lisp article
To: CARL at MIT-AI, jra at SU-AI
CC: BAKER at MIT-AI
The article would be a review of the list representation issues and
how they interact with the garbage collector.
I would hope that the advantages of garbage collection would be included
in another article; if not, I will include some of them.
I will not present a particular scheme for a particular micro-computer.
(The idea of making a usable lisp for a 64kbyte machine is ridiculous).
However, I will review several schemes for encoding list structure to
take up less space.
One issue of particular interest to me: how much money ($'s) is available
for these articles. The last time I talked to Carl Helmers, the rates
were terribly low.
Henry Baker
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂18-Jan-79 2146 CARL at MIT-AI (Carl Hewitt)
Date: 19 JAN 1979 0045-EST
From: CARL at MIT-AI (Carl Hewitt)
To: BAKER at MIT-AI
CC: jra at SU-AI
Why don't you send us an abstract ASAP? Garbage collection is a good
topic since it was invented for LISP!
Cheers,
Carl
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂20-Jan-79 1445 Boyer at SRI-KL (Bob Boyer) Your book reviewed
Date: 20 Jan 1979 1445-PST
From: Boyer at SRI-KL (Bob Boyer)
Subject: Your book reviewed
To: JRA at SU-AI
I am not suprised that your book got a nasty review. The most recent
experience that I have had with the CR book review method were the
two reviews of Dijkstra's book "A Discipline of Programming." The
book received two rave reviews. I think it's a lousy book, and I
was delighted when Floyd completely panned the book in the American
Scientist.
I recently replied to a publisher who was inquiring about whether to
have a certain book written that I would us your book in a class
on the subject, that you had produced an excellent book, and that
it would be difficult for anyone to produce a better one. It would
certainly take them years.
-------
∂20-Jan-79 1754 RZ at MIT-MC (Richard E. Zippel)
Date: 20 JAN 1979 2056-EST
From: RZ at MIT-MC (Richard E. Zippel)
Sent-by: RLB at MIT-MC
To: JRA at SU-AI, carl at MIT-AI
CC: RWK at MIT-MC, RLB at MIT-MC, HIC at MIT-MC, RZ at MIT-MC
This is to inform you that some subset of us will be submitting a
paper for the August issue of BYTE. The title will probably be
something like "LIL - A Lisp Implementation Language". We will
present a Lisp based compiler for implementing system software.
With the language (compiler and perhaps interpreter) embedded in
a Lisp-like environment, the user will have access to the Lisp
debugging tools. We feel that the ability to manipulate programs
via macros coded in Lisp will speed the code writing phase. This
language should be usable on micro-processors without difficulty.
∂22-Jan-79 0637 RLB,RWK,RZ,HIC at MIT-MC BYTE paper on LIL
Date: 22 JAN 1979 0939-EST
From: RLB,RWK,RZ,HIC at MIT-MC
Sent-by: RLB at MIT-MC
Subject: BYTE paper on LIL
To: JRA at SU-AI
CC: RLB at MIT-MC, RWK at MIT-MC, RZ at MIT-MC, HIC at MIT-MC
We need some idea about how long this should be - of course, it might
depend on how winning the outline is ...
∂04-Feb-79 1226 RWK at MIT-MC (Robert W. Kerns)
Date: 4 FEB 1979 1526-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: jra at SU-AI
CC: RZ at MIT-MC, RLB at MIT-MC, HIC at MIT-MC, RWK at MIT-MC
CC: CARL at MIT-MC
Here is a preliminary outline of our proposed LIL paper. It would help us
a lot if you could give us some idea of how much space we can expect for
this paper, and how many diagrams it would be good to include, and of course
the deadlines.
Preliminary LIL paper outline
1. WHY MESS WITH LIL?
a. Motivation - what is an implementation language? Why do we need one?
b. LIL is not X for X in {LISP, BLISS, C, Pascal, PL/I, assembler, etc.}
c. Post parse-time macros (as opposed to textual substitution pre-parse-time
macros)
i. Used for user-extentions to the control structure of the language
ii. Used to extend the semantics of the language
iii. Used to extend the data structures which the language can handle.
d. Debugging aids via interpretation in LISP.
e. Stand alone debugging aids.
f. Extra control structures not found in other languages.
2. WHAT IS LIL?
a. Overture - What LIL offers, generally - functions, variables, pointers,
special forms (control-sturcture contstructs)
b. Syntax - what there is of it
i. lexical scan is easy, (), prefix characters ".' - symbols/number
ii. parse is trivial, explicit list notation
iii. all built into LISP's READ function.
c. Basic semantics
i. Function calling
ii. Variables
iii. . and ' (pointer-follower and address prefix)
d. Special forms (case, select, do, cond, and, or, etc.)
e. Macros - written in LISP, not LIL!
i. LISP is a good language for manipulating LIL code. (Or other code)
ii. Full interpreter available in the compiler.
f. Micros down to machine code level.
i. Give hands-on access to special capabilities of the host machine
ii. Enforce transportability; all machine-dependent code is in the form
of micros; these can be re-coded for new machine, the machine
dependencies have been isolated.
iii. Full user-control of compilation
g. User-defined optimizations.
3. COMPILER
a. Why write compiler in LISP
b. Optimization
4. INTERPRETER
a. Incremental debugging
b. Single step debugging, at source-code level, not machine-level.
c. Why you want both a compiler and an interpreter
5. COMPARE & CONTRAST LIL WITH OTHER IMPLEMENTATION LANGUAGES
a. Detail here that couldn't be included in section 1.
b. Sample program expressed in several such languages
(Perhaps do the core of a BASIC interpreter)
c. BLISS as LIL; show how LISP makes language manipulations easy
6. EXAMPLE AND DESCRIPTION OF WHAT WE'VE IMPLEMENTED
a. Not a lot yet, but we're trying.
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂21-Jan-79 0944 PHW at MIT-AI (Patrick H. Winston)
Date: 21 JAN 1979 1243-EST
From: PHW at MIT-AI (Patrick H. Winston)
To: JRA at SU-AI
I DONT KNOW ABOUT HP THING. ASK ONE OF THE LISP
PEOPLE, SAY RG, TK, OR H.
I HAVE RECEIVED A COPY OF YOUR BOOK AND I HAVE SCANNED IT.
I AM MUCH IMPRESSED. PEOPLE I TRUST THAT HAVE READ IT
SAY ITS GREAT. CONGRATULATIONS ON A FINE JOB.
PATRICK
∂21-Jan-79 1528 BAK at MIT-MC (William A. Kornfeld) BYTE article
Date: 21 JAN 1979 1829-EST
From: BAK at MIT-MC (William A. Kornfeld)
Subject: BYTE article
To: jra at SU-AI
CC: BAK at MIT-MC
What I had in mind for the article is the following:
Show how easy it is to use list structure to represent structured objects
in a database. For example, in a database of student records:
(Courses (Smith John) (Fall 1977) (Calculus←1 Physics Philosophy))
(Courses (Jones Mary) (Spring 1978) (Category←Theory General←Relativity))
(Student-at (Smith John) MIT)
(Student-at (Jones Mary) Boston←University)
and show how easy it is to write a pattern matcher to allow you to allow
you to get records for John Smith for 1977 by using the pattern:
(Courses (Smith John) (? 1977) ?)
This could then lead into a discussion of deriving facts that are not
explicitly stored, such as with the database:
(Mary mother←of Sam)
(Sam father←of Alice)
Who are the grandmothers of Alice? and this becomes code something like:
(when (?man father←of Alice)
(when (?woman mother←of ~man)
(assert (grandmother Alice ~woman)))
This will show how patterned data objects can be manipulated. After this
should follow a discussion of pattern directed invocation of procedures.
Rather than the function call (GRANDMOTHERS Alice) which has to know all
the ways of deducing this from facts stored in the database, there is
a demons that have as pattern:
(when (find←all (grandmother =person))
<...look for a father of person and then his mother ...>)
(when (find←all (grandmother =person))
<...look for a mother of person and then her mother ...>)
(when (find←all (grandmother =person))
<...look for an assertion of the form (grandchild ~person =the-grandmother)
and return the-grandmother>)
and then broadcast (find←all (grandmother Alice)) to invoke all these procedures
simultaneously.
These would get across the basic concepts. Other topics that could be developed
to a greater or lesser detail would be: [1] the kinds of AI programs that have
been written using these kinds of systems and topics such as antecedent versus
consequent reasoning. [2] The idea of "contexts" or having many
databases that form a tree with layering.[3] How these assertions can be coded
much more efficiently in a discrimination net so that access time becomes
nearly independent of the size of the database.
These examples were thought up in the space of a few minutes and more
interesting ones should be easy to find. I think that the hairy macro
characters could be done away with by using mixed upper/lower case or font
changes to make it more readable.
Questions I have:
1. How long should it be (and which of the above auxiliary topics do you think
should be developed the most)?
2. How much familiarity with Lisp should I assume on the part of the reader.
Should I avoid the use of Lisp code? Can I talk freely about recursion
when describing the pattern matcher? How about such topics as quoting or
environments (such as would be returned by the pattern matcher) or avoid
these issues totally?
I will be available to devote time to this starting in about a week. It should
hopefully not take too long to write.
Concerning my master's thesis, right now I'm summarizing it in a paper for IJCAI
and I'll send you a copy of this as soon as it is completed.
Hope to get your comments on this soon.
--Bill
∂03-Feb-79 1116 BAK at MIT-MC (William A. Kornfeld)
Date: 3 FEB 1979 1416-EST
From: BAK at MIT-MC (William A. Kornfeld)
To: jra at SU-AI
Hi. Are you still interested in the article on pattern directed invocation?
I have time now to devote to it. I would like to know when it has to be
done by and approximately how long it should be.
--Bill